[ / / / / / / / / / / / / / ] [ dir / arepa / bestemma / fascist / hispint / litpat / nariz / qanon ]

/emacs/ - Emacs

GNU Emacs and Friends


Subject *
Comment *
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
(replaces files and can be used instead)
Show oekaki applet
(replaces files and can be used instead)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 5 per post.

Getting Started | Need help?


This is the thread for exchanging questions and metorship among fellow hackers. Before you ask a question, try using Info Mode, a GNU Emacs mode for interfacing with GNU/Linux's hypertext manuals. It contains documentation for a majority of the GNU Coreutils as well as all builtin Emacs packages and features.

You can access Info Mode by issuing 'M-x' info or 'C-h i'.
You can learn more about the mode your point is in by using 'C-h m'.

Here are some common Info commands to get you started:
• 'i' - Search through the manual's indexes for a regexp
• 's', 'C-s', or 'C-M-s' - Search for a string or regexp
• 'g' - Go to a node by name
• 'm' - Choose a menu item
Also consult the sticky's resource pages.

1 post omitted. Click reply to view.



I was actually going to write a long post about this in the Package Appreciation Station, but you use Emacs as your X window manager with a module called EXWM by ch11ng, which works in conjunction with XELB. It's interesting, because it will embed X windows into the Emacs frame and treat them as their own buffers. At this point, you can just read documentation on the Wiki page: https://github.com/ch11ng/exwm/wiki

It prefer to start Emacs as a daemon and associate mime-types with emacs-daemon so that you don't accidentally open instances of Emacs within Emacs. Unless you're using something with systemd, though, I found that it's not a good idea to start Emacs as a service with your init. You could write something like this in your xinitrc:

emacs --daemon -f exwm-enable
or you could start the daemon after Emacs opens, but the important part is that the server starts afterwards, or else the embedding doesn't work.

I also like these two hooks:

  (exwm-manage-finish .
(lambda ()
(when (string= "mpv" exwm-class-name)
(setq-local exwm-input-simulation-keys nil)
(exwm-update-title .
(lambda ()
(exwm-workspace-rename-buffer exwm-title)))
They're being expressed with the use-package macro, but you probably understand what I'm trying to do. The simulation keys are really powerful, because they can redeem a piece of software's shitty keybinds and make them emulate the far better Emacs bindings instead. Here are my global simulation keys:
  (defvar qrthi/default-simulation-keys
'(;; movement
([?\C-b] . left)
([?\M-b] . C-left)
([?\C-f] . right)
([?\M-f] . C-right)
Post too long. Click here to view the full text.


Welcome to /emacs/!

Welcome to /emacs/, ∞chan's board dedicated to discussing the highly-extensible family of text editors known as Emacs, primarily GNU Emacs!


NSFW Content

This is a SFW board; however, NSFW (nudity, gore, etc.) material may be uploaded so long as it is spoilered. Assume spoilered images are not safe for work.

Posting Images

Images aren't necessary in order to post an OP, so don't post an image if it's there solely for the purpose of garnering attention. It's okay if you post an image unrelated to the topic of this board or thread if it pertains to a conversation in a thread, but be respectful to your fellow boardgoers.


Try visiting these links for more information and commentary:

Selecting a keyboard, keymap, and interface for GNU Emacs:


Useful guide for Emacs content creators (e.g. Videos, Music, and other Media) for platforms such as YouTube or Archive.org:


Resources such as sites to reference, books to read, and packages to install for GNU Emacs:


For the moment, things are a little bit sloppy. I wrote a draft on all the minute little morsels of info people could use to further themselves with Emacs, but this site's format isn't really conducive to autistic essays (autistic rants, on the other hand…), so I made a small blurb in org and exported it to markdown. Sorry.

Post last edited at

File: 1452641208022.gif (10.26 KB, 388x145, 388:145, xemacs.gif)


According to the XEmacs beta mailing list, the development of it is now officially dead.

Does that make you happy, or sad? Or are you just "who gives a shit?"




Sad, that link doesn't even work anymore. Guess it's really supremely dead.

By the time I started using Emacs, GNU Emacs was back in the lead, so I pretty much don't care.



It's weird that people are still fixated on the novelty of an Emacsen whose biggest claim to fame was that it supported font locking where Emacs didn't. Sure, there was a point when the project could have been justified as something more than just needlessly divisive, but its most notable features have been deprecated for decades.

And "sane" defaults make no sense in the Emacs world, where things are meant to be extended–even less with the advent of version control and code hosting sites. Maybe XEmacs could have pushed its relevancy by making a Wayland build, but first they'd have to make an actual GTK frontend for GNU Emacs. The truth is, XEmacs went the way of most obsessive projects, where they forgot how innovate. Programs are meant to be maintained. A "better" solution isn't something that can be found, it's a relative concept. In the same sense that there isn't just the one bug, maintaining a project is a formative process that has no end. Writing a Wayland build is one feasible way XEmacs could have continued their endeavor to trump GNU Emacs, but it's not the only solution out there. If there wasn't a will to change their solutions to fit their changing world and changing needs, then XEmacs was never really an alive project to begin with. There's no point lamenting something that was inherently dead.

File: 4d8bf7ce8932e28⋯.gif (214.03 KB, 580x580, 1:1, out_1.gif)


Full disclosure, I nuked the other thread because it was old. This is your friendly reminder that you really shouldn't be moving the cursor everywhere you go. "A GNU Emacs package for jumping to visible text using a char-based decision tree" doesn't sound useful, but it really is.

It might not seem useful on Vi or some facsimile because it's really specific and you could just scroll down or move the point to the word you want, but, honestly, Avy is very much worth how disorienting it might be to use if you're used to just interacting with visual lines.

Especially if you're not interacting with visual lines, and there's a specific word you want to interact with—like, say, to browse-url at point. Or to lookup a word with dictionary.el at point if you're reading a book. Unlike most editors, GNU Emacs thrives on interacting with things with your pointer. There are a billion functions and could feasibly write now that you can leverage Avy.

8 posts and 3 image replies omitted. Click reply to view.



Interesting. I didn't expect you to redefine browse-url-function like that. What you're doing with rss-browse is kind of redundant, though, because you can tell browse-url-browser-function to open different url's with different programs very easily. For example, here's my browse-url-browser-function snippet:

(setq browse-url-browser-function
'(("8ch.net" . browse-url-generic)
("exhentai.org" . browse-url-generic)
("github.com" . browse-url-generic)
("groups.google.com" . browse-url-generic)
("melpa.org" . browse-url-generic)
("paheal.net" . browse-url-generic)
("rbt.asia" . browse-url-generic)
("stackoverflow\.com" . browse-url-generic)
("swfchan.net" . browse-url-generic)
("twitter.com" . browse-url-generic)
("youtube.com" . browse-url-generic)
(".*google.*maps.*" . browse-url-generic)
;; ("youtube.com" . qrthi/browse-url-mpv)
("." . w3m-goto-url-new-session)))
On the bottom, you can see a defined a simpler browse-url function; whereas everything else that doesn't fit the criteria above is sent to w3m. There is a disadvantage to this, though, in that you would have to define a specific regexp that would separate YouTube's the results page from the video page, and, even then, that means you can't browse comment. That's why I prefer to just manually select the URL or explicitly call the mpv function when I want to watch a video.

This is kind of tangential, but if you're using Emms, which know has the mpv library, you can open your url in emms-play-url rather than your custom function. The disadvantage of this is that it might interrupt your music or other media, thus why I don't use that, either.

You could also just let xdg-mime manage your url's like so:

(setq browse-url-browser-function 'browse-url-xdg-open)


File: b5c0e56af1da5be⋯.gif (2.56 MB, 300x424, 75:106, terry-dance.gif)



He's not even hiding his degeneracy.

I follow the new packages coming out from the sacha chua blog. There is the source of how she generates the news on her github.

Just to share some packages, sunrise commander is a clone of midnight commander, that is good way of organise your files.

avy, multiple-cursor are obligatory.

swiper/ivy is what I consider the successor of helm.

bury-successful-compilation is very useful to spare time.

undo-tree is extremly useful, as it shows every modification as a tree.

smex allows the most used command to appear at top when M-x.



Not that I need to rationalize it, but Exhentai is a great database for artbooks, especially when pertaining to digital art. It's a sad state of affairs when it's easier for a teenager to watch Anal Milf Barn 74 than it is for a teenager to watch an art film at the theatre, but porn is also a good standard for what is culturally relevant and what lay people like.

Regardless, I love avy a lot, particularly avy-goto-word-1, but a lot of extensions for avy are very limited are completely superfluous.

Multiple-cursor is completely redundant when you can just write macros and employ them far more efeectively.

Counsel/Ivy is a fundamentally different completion paradigm to Helm. Ivy's emphasis on simplicity is precisely why Ivy's extension ecosystem is so small, and most Ivy users use Helm in conjunction. This isn't a reflection of the technical superiority of Helm, it's a testament to the fact that the only people who perpetuate the Ivy/Helm dichotomy are MacOS hipsters who have never had three windows open in a single frame on their tiny Macbooks in their entire life, except when a pop-up buffer appears. If you want to think in terms of sheer quantity, Helm can be controlled by pop-buffer while Ivy cannot; Helm can be shackled to the minibuffer just like Ivy; and helm can occur in its own larger, vertically-split buffer, which Ivy cannot. And its very revealing just how much you know about Ivy when you conflate Counsel with Swiper, is a completely unrelated package for isearch. I know this because I use swiper-helm for Helm, and it works far better than helm-swoop.

Undo-tree is a matter of taste. It's better than simply undo/redo, but that's the problem: undo-tree overlaps GNU Emacs' elegant, simplistic linear undo path for the far inferior undo/redo tree-style undo paradigm. Whereas the latter, again, is completely linear and thus doesn't need an extra module to navigate your entire undo path, undo-tree is a tool that you need in order to manage pruned undo branches, making it a hackey amendment to a meme-style undo paradigm. But it's good if you're used to it,Post too long. Click here to view the full text.



I forgot to say, bury-successful-compilation is a very nice tweak. I'm not sure how it's a time-saver, but it's nice.

Sacha Chua kind of freaks me out. I can't tell if she's being ironic or not. I appreciate her affection for Emacs; even if it is a little shallow, it's easy to tell she's sincere, but I really hate her because she uses MacOS and Google platforms and doesn't even feel ashamed.~



>undo-tree is a tool that you need in order to manage pruned undo branches, making it a hackey amendment to a meme-style undo paradigm

That's some pretty wrong opinions you've got there dude.

undo-tree and the default Emacs undo system are equally powerful. undo-tree could be just as well implemented purely as a visualizer for the default undo system, it would just be slower.

The main reason to use undo-tree is that… it's really hard to remember the history of all the editing that you've performed without some kind of visualization. That's why undo-tree is objectively superior.

Also, both Helm and Ivy are overcomplicated unnecessary packages, just use ido, it's perfect, stock Emacs has everything you need*

*Except for undo-tree

File: aebb87e293cf4e1⋯.jpg (15.14 KB, 200x300, 2:3, wpid-amelia1.jpg)



>A friend who was much older than me told me that I would need Emacs to write TeX

>I didn't know that it wasn't true, so I learned how to use Emacs. It's almost 10 years later now, and I'm not a mathematician nor am I particularly good with TeX, but I do still use Emacs and org-mode.

w2w (Want to Wife)


I don't blame her, org-mode is a miracle, it changed my life for the better. I can't imagine living without it anymore.



I personally loathe org-mode. It falls into the category of those narcissistic little packages that try to impose their own paradigm onto the existing one, like paredit, which overwrites functions as fundamental as deletechar with its own function. Which is fine, except it also means its impossible to use packages like hungry-delete in a sane way, and paredit provides no alternative for that means.

I try not to be biased since the author uses MacOS, but it really shows. Until very recently, org-mode overrided the place for user bindings under the standard user command prefix, C-c, to make room for their own prefix. That isn't even some stupid, arbitrary Emacs archaism. Literally everyone who uses Emacs to any meaningful capacity knows prefixed bindings provided by packages need to be followed by another modified key. And why C-c of all prefixes? That isn't even mnemonic, so, even in that respect, org-mode doesn't respect the sane parts of Emacs tradition. I won't complain, though, since it was changed, but it's an important testament to org-mode's hubris.

The prime example: window management. Different org-mode functions rely on completely different window mechanisms detached from the already existing pop-window mechanism. Why? Presumably because none of the authors really use Emacs in full screen. They don't use EXWM, they use Emacs in tiny frames on their flimsy Macbooks and have never considered how GNU Emacs fares on the operating system it was literally made for authoring.

org-agenda-window-setup and org-src-window-setup can be mediated to behave tolerably with the variable current-window, but it neither respects nor emulates pop-window, and it still reverts all the windows in the frame after the buffer is buried. The former relies on org-agenda-prepare-buffer, and the latter uses org-src-switch-to-buffer. They could feasibly be altered to use one mechanism–not necessarily an existing one that literally every other package uses–but, naturally, no one familiar with the code base has ever bothered. Unpleasant but tolerable.

org-export-dispatch, on the otPost too long. Click here to view the full text.


Im not a programmer. I still want to learn emacs to read, manage and write text. Pdfs, ebooks, shit like that. I would take notes with it too.

Sometimes I like to fiddle with linux too, but not spend too much time on it. Do you think it's worth it, or is emacs hard to learn?


Just do the emacstutor and read the sticky, and if you have any specific questions, there's also the help thread.

File: fccfdbf0f4462d7⋯.png (11.8 KB, 1024x1024, 1:1, windows-10-logo.png)


At some point GNU started releasing official 64bit builds for it. emacs-w64 unofficial build at Sourceforge is now obsolete.


Firstly, we have a questions thread. Secondly, if you aren't even capable of helping yourself enough to visit the official site–even do a web search–what makes you think someone else is going to help you?



>thread has no question

>thread points to official site

Okay fuck it I'm out of here, I don't like boards inhabited by retards.



Take a second and think about what you posted and how it would be interpreted. Here you are, making a thread asserting that there are no builds for Emacs for w64 when a cursory search for the thing would tell you that there is an existing Source Forge site with an unofficial 64-bit build for GNU Emacs carrying on where the other project left. In fact, there's an entire Stack Overflow page about this.

So, either you are so abysmally stupid and are purporting something that is blatantly wrong, or you're simply asking a question in retarded, broken third-world English–which, judging from your broken, semi-coherent sentences isn't a tough inference to make.

The former means is a blatant admission that you're an idiot with no excuses not to justify everyone shitting on you. The latter means that someone can politely nudge you in the right direction and make you reevaluate your lazy, half-assed conclusions.



may you kill yourself please



How does one become so butthurt they reply to a week-old post?

File: 951f445af2952c9⋯.png (36.87 KB, 561x471, 187:157, scrot-2018-05-28-T17:42:44….png)



Literally less than a day out the gate, and some people are having kneejerk reactions about a "systemd unit file" whose existence being acknowledged is more for the sake of pedantacism, since Emacs could be initiated by systemd well before this revaluation. Yet they somehow glaze over Google Drive support, so we'll see how that unfolds in the future and what Stallman thinks of that.

Now that's out of the way, Emacs 26.1 has been released. This means very little to the 1.5 people who post here, but if you're a new boardgoer, this might be interesting to you.

Highlights of this release include:

- Limited form of concurrency with Lisp threads

- Support for optional display of line numbers in the buffer

- Emacs now uses double buffering to reduce flicker on the X Window

- Flymake has been completely redesigned

- TRAMP has a new connection method for Google Drive

- New single-line horizontal scrolling mode

- A systemd user unit file is provided

- Support for 24-bit colors on capable text terminals
Of the highlights, you might find concurrency, line numbers, flymake, and Google Drive interesting.

It might be worth noting that "concurrency with Lisp threads" refers to the deferred library, not async. They both achieve concurrency to a certain capacity, but they're fundamentally different. You can see a comparison here: https://www.emacswiki.org/emacs/ConcurrentEmacs#toc5

What's also interesting is that, from what I've read in the Reddit thread, the new display-line-numbers is implemented in C than its Elisp counterpart.

To be fair, I haven't been paying much attention to 26, so I don't have the full picture, but from Post too long. Click here to view the full text.



>systemd unit file

This means pretty much nothing other that getting a standard way to do it. You don't want something like grub has where each distro has their own unique patch set to it.

File: 6f1c6f5fda10123⋯.png (594.34 KB, 1280x1112, 160:139, 6f1c6f5fda10123220bf94a858….png)


Yes… let the emacs flow through you

2 posts and 1 image reply omitted. Click reply to view.



I'm too cool for that kind of stuff.


dude just use gnu nano


(defun change-region (start end)

(message (mapconcat 'change-char

(mapcar 'string (buffer-substring-no-properties start end))


^It worked right and printed to message what i need, but

(defun change-region (start end)

(mapconcat 'change-char

(mapcar 'string (buffer-substring-no-properties start end))


^It printed nothing. Why?



;; Oh, of course, each function has string (interactive "r"), and they look like:

;; print-to-message-buffer-function

(defun change-region-a (start end)

(interactive "r")

(message (mapconcat 'change-char

(mapcar 'string (buffer-substring-no-properties start end))


;; dont-print-to-current-buffer-function

(defun change-region-b (start end)

(interactive "r")

(mapconcat 'change-char

(mapcar 'string (buffer-substring-no-properties start end))


;; My question is why second function don't print result to current buffer. I use combination C-u M-x change-region-b




If someone read this thread, I found answer to my question in "Introdaction to Emacs Lisp":

"Interestingly, when you call an interactive function interactively,

the value returned is not automatically displayed in the echo area.

This is because you often call an interactive function for its side

effects, such as moving forward by a word or line, and not for the value

returned. If the returned value were displayed in the echo area each

time you typed a key, it would be very distracting."

It mean my code is right, but I should use function like "insert" for printing to current buffer.

File: a42bceb6c717f6a⋯.gif (21.44 KB, 550x124, 275:62, out_1.gif)


This is a thread for small things you've learned in Emacs.

A lot of Emacs users preach about "learning Emacs" and its huge bank of editing features by learning just one little thing every day. I don't know if that's really an apt replacement for just reading the manual, but I will say that, even having read what has to be a dozen of these Emacs manuals by now, it does fell like drinking like a firehose to get everything down in just a few sittings.

The thing is, most things are learned out of necessity. Language is learned from the frustration that rises from being pulled from your mother's tit, so you're forced to interact with the external world. First you babble and then meaning arises.

The functions of tools are internalized when there's a problem that needs application. Babbling isn't onerously trying out every key binding, babble in Emacs terms is experimenting and exploring, and I'm making this thread to explore the subtle things that you gloss over in a manual.


File: cca7d8623d7e194⋯.gif (25.16 KB, 650x150, 13:3, out_2.gif)

So I should probably share something. The picture in the OP is an example of the function capitalize-word (M-c), which capitalizes a word after point. I could have used the prefix commands, but I wanted to show capitalize-word as kind of the staple of the capitalize functions family, if that makes sense.

For the record, capitalize-region isn't bound to anything by default, but I usually bind it to C-x C-c so as to parallel upcase-region (C-x C-u). In edition to that, there's also upcase-word.

As the OP pic suggests, upcase-region is pretty useful for more things than just upcasing titles after without having to annoyingly manually capitalize the start of every word, although I think that in itself is enough to justify its being bound to a key command. It's good for manipulating files quickly when combined with dired and some kind of macro, too, which makes things much more clean in my opinion.

There's also downcase-word (M-l) and downcase-region (C-x C-l).

As a recap, there's the upcase word family:

upcase-word M-u
downcase-word M-l
capitalize-word M-c

And their "region" counterparts:

upcase-region C-x C-u
downcase-region C-x C-l

Also, here's a picture of me using the prefix command.



Oh, I forgot to mention that these features are disabled by default, which is why I made that post in the first place. You can enable them like every other disabled command:

(put 'upcase-region 'disabled nil)
(put 'downcase-region 'disabled nil)

As their disabled state would imply, they're kind of destructive. User noambitions has a solution for this:

(advice-add 'upcase-region
'(lambda(oldfun &rest args)
"Only apply upcase-region when region active."
(when (region-active-p)
(apply oldfun args))))
(advice-add 'downcase-region
'(lambda(oldfun &rest args)
"Only apply downcase-region when region active."
(when (region-active-p)
(apply oldfun args))))


File: 001966406420999⋯.webm (418.55 KB, 960x1072, 60:67, stream.webm)

File: 86d124c2e109a5b⋯.webm (109.51 KB, 960x1072, 60:67, async.webm)

This is just a quick illustration of how easy it is for you to stream videos via mpv by issuing a simple command in GNU Emacs. A lot of people have all sorts of functions for automatically yanking urls from Elfeed buffers to download from youtube-dl and so on, but I've always found that simply issuing the command in the EXWM runner was quick and sufficient enough.

Beyond that, you can use emms-play-url to play those same videos from the emms-mpv library or whatever you'd like, which would let you manipulate streams through Emacs, but I prefer not to do that for videos, since that obviously interrupts any playlists you might be in the middle of, sort of like in this image, and why stream music when you can download it and listen to it multiple times without wasting bandwidth and time waiting for the music to buffer? I do stream music on occasion, actually, via emms-play-url, but podcasts work especially well since you tend to only listen to those once.

As you can tell, I used the hack in >>74 to kill the url which I then put into the runner (S-&); regardless of whether use EXWM (it's just a simple function, mind you), you can use async shell (M-&), which does the same thing but also shows the output, which is good for tools like youtube-dl, where you want to see that.


File: 34ece092b48b1c1⋯.webm (234.14 KB, 960x1072, 60:67, helm-runner.webm)


By the way, the function for EXWM's runner is this:

;; 's-&': Launch application
(exwm-input-set-key (kbd "s-&")
(lambda (command)
(interactive (list (read-shell-command "$ ")))
(start-process-shell-command command nil command)))

I, personally, will actually bind M-& to helm-run-external-function. Helm's a good runner except for the fact that you can't run arbitrary commands, but that's sort of an issue with Helm itself, really.

File: 1469274140158.png (89.59 KB, 1022x1024, 511:512, Vimlogo.svg.png)


vim thread



Emacs is my guilty pleasure, but because it's so large I use zile on my friends' machines. Vim is good, but doesn't have W3.



Do you not know what tramp is?


It's ironic that the biggest criticism of Emacs is ironically the one thing where Emacs is undeniably superior to all else, and critics don't even realize how incompetent they are.

Delete Post [ ]
Previous [1] Next | Catalog | Nerve Center | Cancer
[ / / / / / / / / / / / / / ] [ dir / arepa / bestemma / fascist / hispint / litpat / nariz / qanon ]