[ / / / / / / / / / / / / / ] [ dir / b2 / f / femdom / jenny / monarchy / otter / rule34 / vichan ]

/emacs/ - Emacs

GNU Emacs and Friends


Winner of the 82rd Attention-Hungry Games
/tikilounge/ - Relax, take it easy

June 2019 - 8chan Transparency Report
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: 8362a9207f190c4⋯.png (37.01 KB, 1245x381, 415:127, fbW5zAWF2lst.png)


pic related is a clicky-clack layout i'm designing.

i want it to help me during long hours of programming and writing documentation on emacs (also gonna write some philosophy articles)

i'm trying to make it comfortable to use for typing and emacs bindings (i like the mnemonic approach), so i based it on programmer dvorak and edited from there.

>i gave priority to parenthesis (i do a lot of lisp)

> some characters used in emacs (! $ &) are better positioned

> i changed 5 (frame control) 3, 2 (split) and 0 (delete frame) to be better to access

> changed the top row to have extra arrow keys and pnfb for navigation

>switched caps and esc

>added an hyper key for the right shift

>put X and C on better positions for prefixes

i still am deciding what i'll to with the two extra keys on the bottom row.

any tips on what to do? any extra modifiers i could use?


Emacs, unlike most text editors, is designed to be extended. That's true of key bindings, too. That's why the prospect of functions classically assigned to more intuitive, ergonomic keys in the context of QWERTY according to a hierarchy of frequency of actions in editors are dismissed in 'lieu' of generally mnemonic chords that are easy to understand and learn across clicky-clack layouts.

Thus, if you're suffering from arthritis, or only have one hand, or are blind, or you're just exhausted by Emacs' default bindings, you can assign major functions and modifiers to more preferable keys, some kind of voice interface, pedals, or anything pretty much anything imagine-able, 'ad libitum'. The idea of forcing any person, hardware, or thing into accommodating Emacs in any capacity, whether that be because Emacs clobbered a file full of space indentations into tab indentations or, well, making some custom, niche clicky-clack layout and pretending it should be used for other people's usage like it's some kind of massive undertaking is kind of ignorant to the core nature of GNU Emacs. The former can be fixed with a package, and the latter, well, see paragraph one.

People flash their clicky-clacks with their own personal keymaps all the time. I don't know why you have to announce it to everyone. Get an ortholinear. Or read the sticky.


Notepad is better text editor than EMACS


Why did you write Emacs in all caps?


If you feel that way use notepad

File: 03f61a40daf6fe7⋯.png (117.93 KB, 1126x450, 563:225, wisp.png)


A while back there was and idea to make a lisp without out the drama of the defining feature (parens). How would you author a hide-show mode for the bracing that would would infer the them for indentation. This would be befinicial as it would 1) decluter 2) enforce a readable style 3) make lisp less intimidating.



I mostly use EWW, but sometimes i wanna use something that requires javascript.

There's icecat, but i don't think you can get emacs bindings on it.

Next browser is still too young. Qute bugs a bit for me.

luakit seems nice, i might try changing the bindings. What do you all use?


Emacs really doesn't have a specific family of bindings; thus, Spacemacs. Even in its default state, modes define their own bindings, you yourself tweak bindings. And then the physically impaired may use pedals or some kind of voice input.

EXWM will translate your bindings to arbitrary inputs for as many programs as you want, and you can define said inputs according to variables like the name of the program, so you don't need to be married to one browser. See >>113

IMO, Next is stupid. Conkeror was a much more authentic interpretation of a browser Emacsen, because it was extended in js and was still abandoned, so what makes them think that a crappy interpreter of Clisp of all things is going to be more successful? Its hardly even an Emacsen: the resemblance is so superficial. Unnecessarily ambitious and impractical, just like people implementing programs in Elisp rather than using a suitable language and making an Elisp frontend. Like, for example, Eww in lieu of w3m.

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.

12 posts and 4 image replies omitted. Click reply to view.



>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



>Helm and Ivy are overcomplicated unnecessary packages

Thank God someone else sees it that way.




>Helm and Ivy are overcomplicated unnecessary packages

That makes very little sense. I would understand you if you were just dismissing Helm, but the fact that you also dismiss Ivy is absurd, because Helm, Ivy, and Ido are fundamentally the same in concept, so you clearly aren't dismissing the prompt completion paradigm as a whole.

This is especially ironic, because Ivy has a significantly cleaner codebase than Ido; part of Ido's lack of features is because you simply can't extend it easily, because it's a hacky project. That's why modules extending Ido (and note that Ivy doesn't have that same ecosystem, because its users actually appreciate itself unintrusive philosophy) are as bad as they are. Ivy is small because it wants to; Ido is small because it has to, although it tries very, very hard to be just like its big brother, Helm.



>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.

That's not a benefit of an undo-tree device, that's a side-affect. That can be proven by the fact that you can linearize the undo-tree package and achieve the same end with a snippet illustrated in this thread: https://emacs.stackexchange.com/questions/31779/how-to-make-undo-tree-linear-undo-tree-undo-redo


It's a pretty useless package, but I like selectric mode



In Irreal's newest blog entry, he shows us this repository, including a lot of interesting historical Emacs code:


It's kind of funny thinking that Julian Assange was once a programmer. Maybe his GNU Emacs contributions weren't noteworthy, but, before I started using webjump.el, I really enjoyed surfraw. I still like surfraw, but that sort of application (e.g. constructing a string out of prompts and sending them to another application) is perhaps the most obviously GNU Emacs-oriented ever there's really no competition. Maybe I'll do a little write-up about webjump eventually, since it's pretty cool.


Here's an article on Multics Emacs, which ultimately made GNU Emacs what it is today:


File: ff7df245314dad3⋯.png (315.03 KB, 1122x1042, 561:521, spacemacs.png)


You may not like it, but you know it to be true.


It's nice for beginners who complain about things like rebinding keychords according to Evil, but anyone with a little experience knows how trivial a task like that is if you want things done right. Even then, it's nice to have a concerted project you can use as reference for your own bindings.

I make this mistake where I scold whiny Vi users who have been so cucked by text editors their whole they simply cannot comprehend that Emacs has more than its default bindings; e.g. Evil, God-mode, but I really do understand them in the sense that you do need something to rally behind, that there has to be a mainline to deviate from before you can think for yourself with respect to these admittedly trivial alterations.



Powerline is ghetto, though. It's not even Powerline itself so much as the fact that every instance I've seen has been either using an ugly, gaudy dark as my soul theme for the haxxor clout or on MacOS user's desktop right next to his Zsh instance, because he's never even heard of Eshell.

I actually can imagine some Powerline themes I might like, but I would never try them out, because Smart-mode-line is simply too useful to switch.





>takes half an hour to load up

so those coming from vi et al will drop it right away

>inb4 use Emacs in server/client

If I can do that, it means I know how Emacs is supposed to be used.

As such I understand how pointless SE is.



Even as a service, I get the impression that Spacemacs actually cuts into some of that startup time by differing packages or something–or maybe it has to do with that evil layer–but maybe that's a behavior that could also be rectified with one of Spacemac's many settings.

When you think about it, the demographic Spacemacs pulls in is ridiculously small, mostly being directed towards Vi users wanting to take the gnu pill. When you read older articles, commentary, and social media, I really illustrates a time when basically everyone regarded Emacs as a respectable text editor regardless of what abominations those fringe Emacs users could muster with Elisp–suckless has articles with pro-Emacs implications, I find OpenBSD commentary with screenshots of Emacs frames, and macOS users still love Emacs (at least, the one's that have heard of it)–but our newest generation mostly doesn't care. Part of the antipathy towards Emacs was simply that it was so valuable to a lot of people; the Vi/Emacs dichotomy, despite being almost as stupid as comparing apples and oranges, was mostly something that revolved around Emacs, and now that Emacs has lost its gravity, the absence of those flame wars kind of reveals how important Emacs was to a lot of people.

One thing you can say about Spacemacs is that it's very polished. Lots of text editors and IDE's emulate Vi, but they don't really think through a modal editing lense. That's in part true of Spacemacs, too, but it's a much more compelling illusion. Beyond that, the community is large enough to curb the apprehension of newcomers and give them a sense that this project they're investing their time into has the support structure necessary in order to encourage proper maintenance, which is an expectation the project lives up to.

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: 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.


It's not hard to learn honestly. I got my wife to use it for editing RsT and css for her blog-type stuff. She was using Libre Office and/or Google Docs (exporting to html) before.

Polite sage.

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.

Delete Post [ ]
Previous [1] [2]
| Catalog | Nerve Center | Cancer
[ / / / / / / / / / / / / / ] [ dir / b2 / f / femdom / jenny / monarchy / otter / rule34 / vichan ]