GNU Emacs Now Has Native Support For GTK Widgets (phoronix.com)
An anonymous reader writes: The GNU Emacs text editor now has merged the X Widgets branch. What this work allows is for embedding GTK+ user interface widgets within Emacs for features like landing MPlayer or a full web browser in Emacs. This allows now for more endless opportunities for the 40 year old GNU text editor. The X/GTK widgets support will come with GNU Emacs 25.1.
Emacs would be a hell of an operating system if someone would just write a decent text editor for it.
I remember when you would say "Eight Meg And Currently Swapping" and that was a funny criticism of how bloated EMACS was.
What's the mem footprint today?
Gentoo, Debian and Ubuntu had switched to libav by default, then switched back to ffmpeg.
https://en.wikipedia.org/wiki/...
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
A very good question. EMACS tries to be all things to all people ... and it is. I've used it since almost the very beginning and can't live without it.
That said, I'm not interested in the GUI stuff because it slows me down, and since EMACS is infinitely customizable I just turn it off. To each his own; some people like menus and so on. I do enable display of in-line graphics but no more than that.
Yes, there is confusion over purpose and direction, but to somewhat justify it, I'll say this. Learning EMACS, which is a big job, is a lot easier with menus and a GUI interface to help get started. Over time you learn the keystrokes and become more efficient until eventually you don't need the GUI (but you can of course still keep it).
EMACS is very much not for everyone, but for those who love it, it's indispensable.
And one more little fact: on my Asus Zenbook, I typically get 5 hours running time with a mixed environment. But if I run EMACS and EMACS alone, in a full screen, I get 10 hours.
Funniest thing I ever saw was a guy who was so utterly dependent on his emacs as to be crippled without it ... and then he's on a client site, on a Solaris workstation he can't install software onto ... and the only editor he had was vi. He was almost in tears (we were too but from laughing at him).
Anybody who is going to use unix-type systems and doesn't know how to do at least some basics in vi is just asking to be made to look like an idiot.
I must confess, I've never grasped this incessant need to do everything from within emacs. I find it tends to create people who spend endless hours honing their editor instead of doing their jobs, and who suddenly can't do anything without all the training wheels they've added.
Seriously, check the damned weather somewhere else.
Lost at C:>. Found at C.
Seriously, this is SUCH a niche product. Everyone uses a VI clone because it's guaranteed to be present on *nux systems.
Emacs is a niche product? I've used Emacs (or XEmacs) on every system I've every used and/or administered, from PCs running BSD, Linux and Windows to just about every known mid-large Unix BDS/SysV system to Cray supercomputers since the mid 1980s. (Running Emacs on a Cray 2 is truly a guilty pleasure.) True I may have had to install (or build and install) it myself, but still hardly niche.
Of course, I *also* know vi/vim for simple editing tasks. For serious programming, I always use Emacs or XEmacs. One can always use the vi/vim emulation mode in Emacs... :-)
It must have been something you assimilated. . . .
At the end of the day, code that goes in meets a few criteria:
1.) (the most important one): Somebody gives a crap.
2.) Somebody gives a crap and actually writes decent code
3.) Somebody gives a crap and gives so much of a crap that they're willing to do an additional 400-500% of work to get the patch into the main codebase.
Seriously, complaining what some nebulous "they" should do something is just stupid. This isn't a product that people buy, no project manager doing focus research on what consumers want, and no manager telling an employee "do this or you're fired".
There's just some guy/gal out there with an itch to scratch, who couldn't possibly care less what you want.
(S)he who codes, decides. End of story.
-- Sometimes you have to turn the lights off in order to see.
The xwidgets branch however promises even more. The main use case (at least from my point of view) isn't really to put normal widgets such as gtk buttons or sliders or anything like that in an emacs window. From my point of view the most important thing is that you will be able to embed whole applications using the GtkSocket widget. This means that you could, for example:
* Have a good PDF viewer embedded in one buffer while you are editing latex source code in another and be able to easily switch between those buffers using emacs commands.
* You could have inkscape running in one buffer and use normal inkscape editing commands for almost everything, except when you are editing text. In those situations you may want to use emacs commands instead.
* You could have a *good* webbrowser running inside emacs to search for documentation online while coding
Of course, the main xwidgets branch also opens up possibililties when it comes to prettyifying a lot of built in emacs applications. However, I don't find that very necessary in many cases. One of the main advantages with emacs is that (almost) everything is text, which means that you get a synergistic effect the more you do inside emacs.
; Witty end of comment for emacs aficionados:
(animate-string "Congratulations to Joakim Verona for getting this merged" 10 10)