I've been going off like a broken record in the comment pages for these posts, since I'm such an Emacs fanatic. But I'll say it again, this release is great! Rectangular mark mode, better web browser -- Emacs hasn't stopped getting better
Rectangular mark mode is really awesome. It makes working with rectangles a lot easier. It is now so well integrated into my workflow that I'm really annoyed when I have to use an older Emacs version.
It's funny, I started using Emacs around 1991 or '92 or so (at University), then I changed to Windows development in about '93 and switched my editor to BRIEF which had very nice columnar editing capabilities.
I used BRIEF for a few years until I moved away from strictly Windows development so I moved back to Emacs. Columnar editing was something I missed so much! But now that I've been away from it, it's hard for me to recall what I used to use it for.
Occasionally I do find that I wish I had it, but I remember feeling so crippled without it for a long time! So, can't wait to get back into it again now that it's available. I think it's one of those things that you start using it and find more and more things to do with it as time goes on. Just my $0.02 anyway.
I don't understand what is there that I can't do with rectangles in Emacs 24.3 (or even way before).
I can already kill (C-x r k), yank (C-x r y), replace (C-x r t) text in rectangles, insert text after the rectangle (C-x r z) or at the beginning of all the rectangle lines (C-x r a) or their ends (C-x r e).
Thanks. So that's what other already said, there is nothing more. This was a really minor issue, I don't see why it would make anyone that much happy, but it's sure nice to have it fixed.
It also gives you a live preview when you use C-x r t to insert text, like iedit-rectangle-mode always did (iedit is still more robust, but for most simple cases I use C-x spc now instead of it).
Did you use the 'C-x r *' keys previously? I'm so used to those that I haven't been able to prove to myself that the new rectangular selection is better... In particular, I use 'C-x r t' quite a lot. What is the 'C-x space' equivalent to that?
I'm curious to know which things are easier for you with 'C-x space'.
> All C-x space does is visualize the rectangular region. You still use all the old binding (C-x r t for instance) to do anything with the region.
Really? Upon reading the release notes, I was excited that I'd probably be able to just use commands like C-w or C-x u to act on rectangles. Sad to see it won't be the case.
It must have been a hard decision to make that change -- the current maintainers really hate breaking defaults. I suppose it's just that useful to have.
Interesting - could you please provide some examples of how are you using rectangular mark mode? I have never used it before, so I'm clearly missing something cool here...
Any time you're working with tabular data, or data that is aligned horizontally, it's helpful. For example, I might need to delete a prefix from a list of declarations. I often use macros for the same kinds of tasks, with each macro editing a line and putting the cursor on the next line afterwards.
apply-macro-to-region-lines does not need macros to put the cursor on the next line.
From the manual:
The command C-x C-k r (apply-macro-to-region-lines) repeats the last defined keyboard macro on each line that begins in the region. It does this line by line, by moving point to the beginning of the line and then executing the macro.
At one point there were only two web browsers in the world, one was Mosaic (Mozilla is short for Mosaic Killer) and one was W3 (the emacs web browser).
I don't think Mosaic was the original browser and I believe others predated Emacs, such as Lynx. Here's Wikipedia's version of events, for what it's worth:
I tried to compile emacs statically but under archlinux I need to build ncurses (and probably others) statically too. Which is too much of a black art to me. Gonna try on debian since I believe they include static binairies in packages.
Slightly off-topic, but is there still much NNTP use out there other than piracy related? I was a heavy NNTP user once upon a time, but all the public groups I once used seem to be overrun by spam and private ones seem to have gone in favor of email. I would expect there's a quite a few private servers out there to warrant continual updating in a program like emacs.
Yes! There's a healthy community at comp.misc where we post stuff like this article, and sci.misc where we post non comp stuff. In fact you'll see a healthy correlation between articles posted to Ycombinator that are subsequently posted and discussed on comp.misc and now sci.misc. Good place to get a free Usenet account is Solani.org now that Albasani and AIOE are somewhat over-subscribed.
D development forums are NNTP, although there is a forum as well.
I really prefer the keyboard navigation and all the niceties offered by Thunderbird than the web groups interface, each with its own set of allowed actions, mostly without keyboard navigation.
The problem is that it isn't a good enough Lisp engine to be very good at anything beyond the great text editor, which it has been since the early 1980's.
Avoiding the really hard problems and building a better emacs browser doesn't really help anyone. At some point, people will realize that the concept behind Emacs is great but could be better done in another high performance language. JavaScript in a browser? Clojure?
What? Emacs isn't a big Lisp interpreter. It's a text editor that is extensible with Emacs Lisp. Sure it contains a Lisp interpreter, but saying that Emacs is only a Lisp interpreter implies that the entirety of the text editor is implemented in Lisp, which is clearly not the case.
I use Emacs as a text editor, which means I use it to edit anything that has text. Granted that is a huge part of my computing needs.
I don't want Emacs to be able to do anything. I already have an operating system and a text editor.
Nope, it's mostly a Lisp interpreter. Stallman had to build some of the low-level stuff in C then he built the rest of the editor in Lisp.
"We used the same idea here (in the hybrid technique), that most of the editor would be written in Lisp, but certain parts of it that had to run particularly fast would be written at a lower level"
There's some kind of paradox here. You say it's mostly a lisp interpreter, but then, also, mostly editor functionality written in lisp. I'm not sure you can have it both ways...
It's lisp man, of course you can have it both ways. Code is really data, your program is actually your environment, your editor is actually a giant lisp program with a built-in lisp interpreter. Or is it a lisp interpreter with a built-in editor? I dunno. I'm off to install this release :)
Without Lisp, or something very like it (and javascript is not good enough), I would not use emacs.
I use emacs as a source navigation and exploration tool, even more than for text editing. Its ability to run code customized to the language and projects I'm working on is far more important than its ability to edit text.
I actually don't like a lot of its text editing functionality, and had to work hard to get things like selection, tab indenting, scrolling etc. to work in a way that didn't drive me up the walls. I had to give up on virtual space, one of the things that stopped me learning it 10 years ago. It's also very hard to record keyboard macros without accidentally cancelling (I tend to press C-g reflexively when I type a wrong shortcut); I use multiple cursors these days instead, even though that is much riskier / harder to use when you can't see the whole buffer / all edit locations on screen at once.
A browser, I don't really need that per se - unless it's linked to library documentation. But it's hard to integrate modern docs without at least understanding HTML, if not HTTP. So I can see the need for a browser implementation.
Emacs is in essence, a virtual machine: http://www.emacswiki.org/emacs/ByteCodeEngineering. That's why you are able to do so many things with it. The whole text editor GUI is just a frontend the Lisp interpreter. You can think that Python comes with an interpreter that runs in terminal. Emacs comes with an interpreter and a whole GUI frontend for its interpreter, not merely a terminal interpreter with a prompt. That's why you are able to evaluate any Emacs Lisp code ANYWHERE.
If you only use Emacs as a text editor, that's fine for using a subset of it. Just like a casual user uses Linux without never using its underlying tools in the terminal.
> saying that Emacs is only a Lisp interpreter implies that the entirety of the text editor is implemented in Lisp, which is clearly not the case.
With this argument, I guess Python is also not an interpreter because clearly it is not entirely written in Python.
The actual Lisp interpreter is rather tiny compared to the other stuff. Just do a 'ls -l *.c | sort -gk 5' in the src directory. By far the largest file is xdisp.c, which is the redisplay engine, and only a handful of people in the world dare to touch it. Next comes input handling (keyboard.c), then then dealing with coding systems, terminals, win32-API, image handling, windows, processes, buffers, and much more. AFAICS the first file to actually deal with Lisp is lread.c and comes in at #21.
I agree - a great update. I especially like it when I am in -nw terminal mode and being able to use F10 to get access to the menu items I don't remember the shortcuts for.
Alternatively, until homebrew is updated you can run brew edit emacs and change the url and sha256 to match 24.4, then run brew install emacs with whatever options you would like (brew options emacs for a list). I haven't tested this yet, but it should work, and I will report back after I've tried.
edit: So this did work, I used the .tar.xz with sha256 47e391170db4ca0a3c724530c7050655f6d573a711956b4cd84693c194a9d4fd. One thing to note is that the old 24.3 stable formula has a bunch of patches applied that are no longer required, so you need to edit those out as well (this area: https://github.com/Homebrew/homebrew/blob/master/Library/For...).
For 2 or 3 years now, whenever I have compared the two, the current version of "Mitsuharu" Emacs has always had fewer Cocoa-related bugs than the current (release) version of "FSF Emacs" (i.e., Emacs without the professor's patches applied). I am writing this comment because this Mitsuharu fellow seems very reticent about promoting his own (excellent) work.
True, I didn't find any notes on what key to use and the key I typed in is the one the signature itself said was missing (so it is in fact a bad choice). Your criticism is valid. Sorry if I misled anyone, I meant to fix that but I didn't find much guidance on the gnu site as to what signatures to load to bootstrap trust.
Just a note: I think I was hoping (but didn't confirm) that I was downloading the key from GNU and the file from a mirror. So I thought I had the minor protection that I was at least safe from somebody who could only alter the mirror. But I agree with the criticism: not being clear what you are claiming to actually check in a crypto-situation can confuse others and cause harm. Sorry about that.
No worries, end to end PGP leaves a lot to be desired, but I feel it's important to point out when the common recipe steps fail to protect against exactly the adversary one would think they do.
I'm a comparative youngin to most of the people here, and I've never tried emacs. I'd like to learn my way around it someday, but I don't know how high of a priority I should place on it. I've managed to pick up enough vim to make my life easier, would learning my way around emacs also get me a productivity boost? How good is evil mode?
I spent a couple of years using vim before switching to emacs around 3 years ago. I'll write about my own experience with both editors.
Learning emacs won't automatically give you a huge productivity boost the way learning vim does. Vim is this blazing fast editor; it's been designed from the ground up to be good at editing text. If your goal is to increase your productivity, I'd say invest time learning vim advanced features, like jumps, macros, registers, and the plethora of other things I don't know about.
Emacs is not about speed. It's about control. It's a fully customizable environment to manipulate text. You can use it to edit prose, code, scientific formulas, but also emails, IRC/Jabber clients, clients for virtually anything with a REST API. Here are some of the use cases that make my work easier using emacs:
+ Evaluating pieces of code at once. I write a lot of Python. Most REPLs out there allow editing of one line at a time. emacs allows me to fire a python interpreter and evaluate regions (multiline function definition, or data structure) at once. Similar features exist for other "dynamic" languages.
+ Better code review workflow. I receive code review requests via email immediately inside emacs. I can play with the diff files, the source files. I can make modifs or run the code without leaving my editor. And since the code review system has an HTTP API, I can even post my comments and votes back.
+ Org-mode (http://orgmode.org/). I would use emacs for this module alone. It's a note taking system that can easily transform into an agenda, todo lists, memo, document markup, tables (oh, the org-mode tables!), ...
Basically, to answer your question: I think you'll get a lot of benefits from emacs if you enjoy customizing it and integrating it to your workflow. If you don't like spending time customizing and prefer something that will just make you write text (well, code and configuration files) faster, stick to vim and spend this time learning advanced commands.
Emacs allows you to use basic commands like any other editor, but to be blazingly fast you need to use the controls explained in the tutorial (plus some extra stuff that you can pick up later). The tutorial is not optional if you want to be blazingly fast.
It's probably true that if you come from vim to Emacs that you won't get a huge editing boost as such, but I think the reverse is probably also true.
I would say that learning your IDE or editor well is a worthwhile investment, whether that is emacs, vim, or a more rich IDE like Eclipse.
Vim or Emacs are really powerful tools that will serve you well over your entire career, so getting adept at them will pay dividends. It's similar to learning how to touch-type, or typing with a faster WPM, in that it's not a pre-requisite to becoming a good and productive developer but it certainly helps.
Emacs is my personal favorite editor, and I've found that the more adept I get at using it, the easier it is for me to get into "flow" and be productive. I don't use my brain's CPU cycles to fumble around trying to manipulate text as much, since through repetition and muscle memory I can work at it effortlessly (compare that to someone who has to two-finger peck while programming).
Similar to other powerful tools though, becoming good takes practice and a time investment. But I would argue that the initial upfront investment will pay off in the long run.
TL;DR: Yes, absolutely. Learning Emacs (or Vim/SublimeText/Eclipse if that's your choice) well will definitely boost your productivity in the long run.
Happy to see others mentioning eclipse. I'm learning emacs now and it impresses me a lot but I also have happy memories from both Eclipse and NetBeans.
The way you can refactor whole projects at once etc is amazing. (This is partly related to Java being static and uncool as well. : )
"would learning my way around emacs also get me a productivity boost?"
No. Although I first used emacs roughly 22 years ago so my memory might be rusty, the learning curve was extremely steep. Its not a GUI app with low maximum performance but very short learning curve, its more like something you'll have to mess with for a month to year to wrap your brain around. Its like learning dwarf fortress vs angry birds. In the very long run you'll probably like DF more, but not for the first day / week / month.
I beg to disagree. I learned me an emacs around the same time period (mid 90's). I don't remember the learning curve to be that steep. I started by doing the tutorial. If you download a GUI emacs (e.g. from http://emacsformacosx.com/ ), and open the program, you'll see a mouse clickable invitation to take a tutorial. Do this. Don't take shortcuts. Just spend the one or two hours and go through the entire tutorial complete with practice exercises.
Or if that's intimidating, start by reading this gist:
Sorry for responding late, but completing the tutorial merely brings you up to the level of using vim. Like, OK, hit C-x C-s to save instead of esc :w to save. That doesn't really help, it just teaches equally productive keystrokes.
You can "rise above" by using emacs but its going to take a lot more than learning a different keystroke to scroll the screen. Learning all the features of your language mode, its debugger integration, integrated refactoring tools, project tool integration, it all takes time, and those are the areas where you get huge productivity gains when you put in the time.
I agree you are correct that the FIRST step is the tutorial but that won't provide any performance gains over any other bare text editor.
For what it's worth, I learned Emacs out of my desire to learn Clojure. It didn't take too long to develop the muscle memory (a few months of forcing myself to use it). Now, 6 or so years later, I use Emacs for essentially all ad-hoc text editing jobs, and of course Clojure dev. I love using it for my shell (M-x shell) - being able to move about the shell buffer w/out limit is very liberating.
I also do a lot of iOS development, and, I do 95% of editing in Xcode, and 5% in Emacs. A nice thing about Emacs is, if you're on a Mac, is that Mac OS uses most of Emacs' movement keybindings, so even when I'm in Xcode (or any other app for that matter), I can still use my Emacs muscle memory.
I'm not that young; 6 years ago I was 30, and I'm very happy I decided to learn Emacs; no regrets. It's still paying dividends today and will continue to for the foreseeable future.
There is this incredible tool called Karabiner (https://pqrs.org/osx/karabiner/). Among the many things it can do are Emacs key bindings. I used it to enable more Emacs key bindings in OSX, for example M-f and M-b.
A slightly different target audience, but here is my Woodnotes Guide to Emacs for Writers (not Coders). It will get you used to the editor, at least. I use Firefox plus the "It's all text" extension (configured to call emacs as its editor) for happy times on forums like this one.
http://therandymon.com/index.php?/archives/197-Woodnotes-Gui...
For some (usually specialized) languages, emacs is easily the best IDE/editor, so if you want to use one of them, give it a try. Its key combinations are less ergonomic than vim's, so you should definitely spend some time configuring your keyboard if you're going to try it. (I'm being serious.)
I found out about evil mode two days ago from the 24.4rc1 post, and so far, it feels like vim but a little wonky. The great thing is pressing C-z in evil mode toggles between vim/emacs modes and is very convenient.
Seriously? I played around with emacs this weekend, and used it exclusively at work today.. I kept restarting it because I thought evil was bugging out.
I'd agree that evil mode is quite nice, and emacs seems like something useful to know. It really depends what you prefer. I'm trying out emacs specifically for the formatting plugins as vim seems to fall behind in that regard.
You could just try it. It won't take long to adjust to, and you can stick to basic things so that you will be no less productive compared to working in any basic text editor. There are some things that you will have get used to in order to be able to use it at all, such as the seemingly archaic kill/yank functionality that is used instead of copy/cut/paste. And of course you want to test drive some of the more advanced features, to get a feel for what is possible in Emacs. But the point is that you can ease into these things; you won't get easily lost or overwhelmed.
What you should perhaps be more concerned about is whether you will be able to go back to a plain text editor, once and if you choose to go down this rabbit hole..
I think this thread is my best shot at getting this question answered.. I've been using Emacs 23.x for the last several years because the buffer-switcher behavior changed in Emacs 24 and I have no idea how (or if it's even possible) to get the previous behavior back?
In Emacs 23 and below (for as long as I've used Emacs), I would change buffers by hitting F10-b (F10 brings up menu, b is shortcut for Buffers).
Then there is a nice little list of open buffers and the first letter of the filename is usually the shortcut to switch to that buffer.
This made it really fast to switch back and forth between multiple files (I want to go to index.html == F10-b-i ; now I want to switch back to about.html == F10-b-a), it was very simple.
Emacs 24 changed that behavior and so the quick switching between buffers based on the first letter of their filename went away.
Does anyone else know what I'm talking about? Is it possible to get the previous behavior in 24? I'm slowly finding packages that won't compile in Emacs 23 anymore b/c they depend on new Emacs 24 elisp functions. I only ever use Emacs from inside a terminal (emacs -nw), so that's why I'm navigating buffers by the F10 menu.
EDIT: Well, I may be an idiot. I just downloaded the latest 24 build and it seems to be working as before again! Not sure when this changed, but maybe this is now a non-issue. I feel a bit silly, but maybe this will help someone else?
That's slightly different. It will prompt for a buffer name, which you can type in and tab-complete, but it's not quite as fast as the one-key switching (also it doesn't show a list of buffers unless you try to tab-complete while the prompt is empty).
With ido-everywhere, flx-ido and ido-vertical-mode you can get nice, fast buffer-switching with fuzzy matching via C-x b. See these two screenshots for an example: http://imgur.com/a/sZk8m
I've tried helm a few times but I can never stick with it. It definitely looks impressive, but I think it takes up too much room and I end up preferring the minimalism of ido in comparison.
In Ubuntu I'm unable to activate orgtbl-mode unless I first switch to org-mode. This didn't happen with Emacs 23. Has anybody experienced the same? How can I check if this has been reported? Thanks.
Edit: Seriously, people? You take the time to downvote and not to point in a direction to contribute to make Emacs better? So much for the attacks on Stack Overflow and its strict policies and policing... And anyway, how off topic is this comment? Peace.
Try adding (require 'org-table) to your .emacs. My guess is that you only have (require 'org-install) or something like that currently. (Running the org-mode function will load several org libraries, including org-table, if they aren't loaded already, which is why orgtbl-mode does work after the first use of org-mode in the setup I'm guessing you have.)
Thanks a lot for replying! That did it! Although I haven't tried the latest version, I know for a fact this wasn't necessary with version 23, which is puzzling.
Thanks, wging, I will keep that in mind. Still, I wish HN were more open to these not-so-off-topic questions. Happily, I have received an on-target reply, which rocks!
I'm asking for guidance, since I don't know where to file what I consider a clear bug, and where to check first. (Ubuntu? GNU?) Instead, I already received a downvote and this... Thanks, anyway.
Probably an Emacs-specific support forum would have been a good choice, assuming you used Google first and didn't find anything. HN certainly was not. I didn't downvote you, but it looks a lot like you didn't try to do your own homework, because it's not that hard. Either one of the places you mentioned would have been better. That's probably why you were downvoted.
Thank you, Andrew. I guess I can also see why I could be downvoted, though it is sad that those with downvoting powers don't let not-so-thrilling comments "just sink" to the bottom of the page instead of downvoting, which in my mind should be left to destructive, offensive or just completely unrelated stuff. Best regards.
If you're looking for GNU emacs on Mac OS X, this is the place I use [1]. Note that it's not there just yet, so be a bit patient. They've been doing RC builds, you can seem them here [2].
Short version: Lunaryorn: "I used to get them from Emacs for Mac OS X, but now I use Homebrew, because it supports more libraries, notably GNU TLS for encrypted network connections.
All in all: Use brew install emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick :)"
Thanks for that! I went through this on my own quite some time ago and came to my own conclusion that GNU emacs is the one for me, especially since I do program on mac os x, Linux and Windows.
EDIT: Well, now that I've read that in full, I'm thinking of giving the author's conclusion a try:
> All in all: Use brew install emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick :)
Weirdly, 24.4rc1 from the builds section is really wonky on my OS X Mavericks install. On scroll, the buffers go "above" the window and the top bar breaks up into tiny pieces and scrolls with the content. Ugh.
Perhaps some weird kind of font issue? Try setting a different default font, and seeing if that does anything. (The font popup is bound to Option-t by default, I think.)
Does anybody have an idea of how much time is the windows version release usually delayed? I´m finding myself checking the page frequently, but there's no related info (that I can find, at least)
Well it is limited by Emacs' display engine. It is obviously not supposed to replace your default browser. But it is usually good enough to view html documentation. Which is really something you want inside your editor.
Actually - it would be cool if there was something that allowed you to render markdown atleast.
Also, is this display limitation a function of the OS? In which case, shouldn't Cocoa/GTK or other versions not have this issue and be able to actually embed nicer rendering in there with nice fonts?
It isn't a limitation of the OS, or of Emacs really. There is a build where you can embed GTK widgets inside of Emacs. It just isn't at all standard or, last I checked, well supported (on the level that the usual Emacs distribution is).
This web browser in Emacs is usable inside a terminal, and it displays HTML really nice. Much better than something like elink. Other GUI web browser is not.
I haven't used eww but I use emacs-w3m from time to time and even though I use a tiling WM as well it's convenient to have regular editor commands work in the html buffer to copy/paste code snippets. Also stuff like hippie-expand will be able to complete symbols present in the html buffer which is pretty nice.
On my Mac for example, the text in Emacs is just as good looking (and in fact is indistinguishable from) the text in a native Apple application like TextEdit or Terminal.app.
Either the resolution of this screenshot has been scaled down in a way that makes diagonal lines jagged, or this particular Emacs has been configured not to use anti-aliasing of text.
Some Linux users prefer or at least are used to it that way.
On X, anti-aliasing (in the form of XFT) did not become available in an Emacs release till the relatively late date of Jul 2009. (It became available in pre-release versions of Emacs about 15 months before then.)
I've been thinking about using a simpler browser for reading simple documents. The motivation is to have a sort of "minimalism", as in using simpler programs to do simple things, and not get easily distracted by all the bells and whistles in a more complex application (like for example Firefox). This, I think, would be aided by using a simpler browser that could for example be run in a virtual terminal for reading things like documentation, in the context of developing where I will need a terminal (and maybe also a graphical text editor), anyway. So then there is less context-switching, presumably.
I am not someone who tries to do everything within Emacs[0] (yet?), but this seems like something that might be able to fit nicely with this kind of style, since I can restrict myself to only using Emacs and terminals for developing and reading online documentation. Does anyone enjoy working/developing like this?
[0] Yes, I see the slight contradiction in wanting to do things in simpler software, and then suggesting doing those simpler things within Emacs. :P
The Eww browser is fully compatible with terminal if you run Emacs non-window mode (-nw option). It supports both HTML and CSS, and render quite nicely. Much better than any terminal web browser I used.
The browser is for looking up online documentation not available in your local machine. For example, sometime a man page is not available in my local machine. I can invoke a google query right inside Emacs and open it immediately without involving heavy weight browsers.
It is really nice to read online book like Practical Common Lisp: http://www.gigamonkeys.com/book/, and directly copy the code and paste to your REPL without ever leaving Emacs.
For distraction free writing, M-x toggle-frame-fullscreen and (set-fringe-mode '(120 . 120)).
There used to be a bug in earlier emacs Versions requiring a Patch for proper fullscreen. Have not tried this for a while, but now it seems to work nice and smooth.
I like writeroom-mode[1] for distraction free writing. I only use emacs in a terminal that's always fullscreen, but I imagine it works just fine in any case.
If one wants to start using Emacs is there a recommended starter package that is recommended over others instead of starting from scratch that can be learned from over time?
I want to start using Emacs, but starting with a blank slate leaves much to be desired. Especially when a someone new to Emacs doesn't know what's available or what can be done or how.
I think if you're the kind of user who just wants an editor that does things for you, you'd be better off sticking with what you have already chosen that satisfies your list of features. Deciding to use Emacs for its features is a bad reason.
If you're interested in Emacs for its extensibility then I would consider it a worthy investment. Go through the tutorial, find out how to query docs, extend keybindings and modes and things like that, and then I would recommend my Elisp programming guide: https://github.com/chrisdone/elisp-guide
Can some one tell me why windows Emacs still does not have a working shell?
One cannot easily run ssh from a shell in windows emacs. I have found that I cannot push to a bitbucket repo that uses http authentication too from the shell. But if I run them from a cmd window, these works fine.
What is the technical issue that is preventing emacs from fixing this?
As far as I understand this, this is a problem with git on Windows. Shells work just fine with Emacs on Windows, it just can't supply the git password for some reason.
Except they don't. File-name completion replaced all backslashes with forward slashes, thus breaking cmd.exe's built-in commands. I reported a bug; it started a short discussion; i was asked whether I had to use cmd.exe (YES, I have reasons for why I MUST use it); nobody really acknowledged it was a bug; the discussion died off in talk about some internal details. (The 24.4 binary package is not yet available for windows so I couldn't test it.)
I actually had a similar problem in the past. My workaround was to use some utilities from gnuwin32, which are native windows ports of the gnu utilities. With that, you can use gnu mkdir, rm, ls etc instead of the cmd builtins.
That is me! That is why I said 'One cannot easily run ssh..'. There are work arounds, like using plink or cygwin emacs and more. But it seems that every one of them is broken in some aspect. For eg, If I use cygwin, the cygwin file paths send to other command line programs (non cygwin) wont work with them. When using plink, the display of escape sequences in the command prompt, like "^[]0;vagrant@ubuntu-14:", and difficulty in working with programs like vagrant that uses ssh indirectly.
And as far as I saw, none of them provides a working auto completion in the context of remote file system. Another thing is that I cannot push to a remote repo using http authentication.
It supports html and css, but not Javascript. It is implemented in pure Elisp.
I wrote a few introduction guides to Emacs and its ecosystem: http://tuhdo.github.io/ . The guides do not include evil-mode though, as I use Emacs key bindings. But installing evil-mode is easy, and you can immediately use Vim key bindings for editing.
Can't wait until homebrew is updated to try this out. A part of me is morbidly curious to try out the new web browser. This may be the impetus I've been needing to make the jump to GNUs for my email.
The web browser (named eww) is of course limited by the display engine of Emacs. So don't expect too much. But for reading documentation in html format it works well for me so far and I guess that's the biggest use-case for it.
It can display images. It seems to even support HTML5 SVG.
The HTML rendering engine (shr) was originally written as part of the Gnus project for exactly that task: To render HTML in RSS and email. The browser (eww) just adds http support via url.el and a user front end.
