Yes, 34 years and no plans to switch.
Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CLI much much convenient and faster than moving hand to reach cursor keys.
My only gripe is that Firefox and its derivatives it doesn't work any more. Long time ago it did work. And I have no idea why feature was dropped some rewrite.
e: s/deadline/readline/g
It's 26 years for me. Emacs is I believe the oldest software I still use. I started on an SGI Irix in 2000. I used it also on HP-UX, Solaris, Windows, MacOS, and of course all varieties of Linux
> Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
And many keystrokes work on MacOS, too. That was a pleasant surprise when I got a Mac laptop for work.
The only problem is, this is not the behavior I want in terminals or in GNU/Emacs itself. I wrote a small python daemon (managed by a systemd user service) which wakes up whenever the active window changes. Based on this info, I send a message to the TCP server that kanata (also managed by a systemd user service) provides for remote control to switch to the appropriate layer.
[0]: https://github.com/jtroo/kanata
[1]: https://gitlab.com/spudlyo/dotfiles/-/blob/master/kanata/.co...
Yes, even in Codex and Claude Code.
> Those work well also besides shells with Chromium/Chrome/Safari... My only gripe is that Firefox and its derivatives it doesn't work any more
Interesting, my experience is exactly the opposite: I had to finally bite the bullet and migrate to Firefox because Chrome/ium switched to GTK4 which removed key themes support.
(That's OK though, I should've moved off Chrome a long time ago.)
Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.
I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.
People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.
Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.
If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.
So customizable- these days Claude will just change it for you, no need to learn the APIs if you're just interested in the result. Yes you're AI-slopping your config, but the drawbacks to that are super low (it's a personal editor, not something I'm inflicting on others)
*) https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
I think you mean readline?
I have never used emacs seriously as an editor, however, I couldn't work without magit. I even manually build emacs 28 so I can re-use the same set of magit configure files.
Specifically none of these do anything like what they do in Emacs: C-a, C-e, C-n, C-p, C-f and C-b.
This is on Linux, but ISTR finding the same state of affairs on MacOS many years ago during some previous iteration of this conversation.
They also don't work in VSCode.
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
Plus a bunch of other things!
https://lawsofux.com/postels-law/
https://en.wikipedia.org/wiki/Robustness_principle
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
I thought it was named Ghostel because of Ghostty and EL (emacs lisp).
Of course. Emacs has been my stable editor over many years, handling many languages that came along, surviving many other IDEs that came and gone (the latest being the Cursor sold out).
There're always new enhancements in Emacs, from multiple-cursor editing years ago, to LSP and tree sitter in recent years. Currently I just got into the vertico/marginalia/consult/embark combo packages. Embark with its context based actions seriously is an amazing underrated package.
1.Memorizing how to use it has a big learning curve.
2.Wrist pain from pressing button combinations all the time.
Otherwise plenty of people still use it and it's great. Just hard to pick up for new users.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
[1] "Evil Software Hoarder Emacs": https://news.ycombinator.com/item?id=26113192
I used have a ep which I could pipe something into and it would put it in Emacs buffer but that stopped working somewhere I never got around to fixing it.
Yes. I use it instead of tmux for that.
For my desktops, I use an Ergodox EZ keyboard and mapped ctrl and meta into the thumb clusters there.
Also claude-code-ide.el. try these
I've been trying to use agent-shell with OpenCode but the abstraction that agent-shell puts on top of it is too much. I can't figure out how to change the model. The command to do it doesn't do anything; I see the correct model list and seem to be able to select it, but then it doesn't change. If I just run "opencode" in the same directory it comes up configured the way I want. The Claude integration works with that workflow too. Opencode comes up with some baby CPU-only model that I've never heard of, and basically, it outputs syntactically correct English sentences but doesn't seem to do much more than that.
Since I mostly use Claude I haven't fussed with agent-shell much yet.
It is crazy nice how invisible the native compilation became.
2. Remove MELPA packages that are now part of Emacs
3. Go to step 1 when new version comes out
Except for tree-sitter. That's something I'll be investing time in.
I can just ask Claude, “make leader / toggle a terminal at the bottom of the screen , and leader t swaps it to the right side” and it’ll just do that. I liked a theme but I wanted it to also change the status line of the focused window, and it just did that for me. I had an issue where the neo tree would freeze for a few seconds, and Claude figured out it was a bad interaction with the git in our toolchain, etc etc.
I have my very own text editor that I customized in plain English! I could’ve learnt spent hours learning Neovim’s style of Lua, researching packages, debugging, etc, but this gets the same stuff done way faster and lets me get to work. This was the biggest thing that kept me going back to either a preconfigured Vim setup like LazyVim or vscode. Definitely recommend.
Claude did my neovim in about 45 seconds, with the instruction “make it work like my vimrc but better and using the cool new stuff” and it’s great! Not my daily driver, but serviceable as EDITOR and prettiest of the bunch.
Even with spaceman’s/doom and the amazing documentation it was always still so much work to configure emacs as a newer user. LLMS have made this nearly instant.
This is a bit of a ramble but it’s so amazing having emacs and an LLM now, I don’t even touch vscode anymore and only find myself touching things like IntelliJ when I really need to dig into something with a debugger.
Using an LLM on init.el is a lot easier than using it in your day job. A 2 line change that you told the LLM to make is easy to internalize.
I’ve been thinking of trying out emacs because I think the native gui can probably be even more powerful
Maybe there will be a resurgance of terribly obscure totally unique quirky configuration files for all these vibe coded apps, unique enough that they don't appear in the training data, so you have to hire real humans to sit at your elbow and help you!
There is Only One. En garde!
I never asked for native compilation implemented via the trampoline technique, which increases attack surface (because it causes Emacs to routinely execute files in a known-by-attackers location in my home directory) and makes debugging harder, but I'm stuck with it if I want my Emacs to speak the Wayland protocol (and I do).
Ditto the clumsy bolting-on of lexical scope.
It also has nothing to do with Wayland.
And what's wrong with adding lexical scope!?
I do have some concerns about certain features but the ones listed do work, and work great.
A) which premade config to choose
B) what half of those settings even do (and do you need them)
C) a lack of “sane” defaults that use the built in abilities
Realistically walking through the article authors “emacs from scratch” config and seeing what can be done with the built in packages and how is hugely instructive but even then you only get that from walking through the config one line at a time and reading “help” documentation for most of it.
At this point emacs is so old that fixing the problem of “sane defaults” is probably near impossible if only for how much it would break existing configs. But it might be a good addition to the tutorial to provide a set of questions and answers (possibly with demonstrations) that allow a new user to generate their own config with some nice defaults. We can assume these days that most new emacs users are coming from some other editors, so asking questions like “do you want auto complete suggestions in an inline drop down like VSCode” could be a perfectly reasonable question and then it could add the correct configuration settings to config for you using just the built in functionality
A small number of people with taste and experience.
Like one hopes to be the case for every opinionated preset profile set.
I think I'm down to about 110 lines of ~/.vimrc now :}
The core editing components of non-Evil emacs are direct manipulation, not modal. That there are modal aspects on top of that for doing things which practically/genuinely need a modal switch (command entry, search entry, etc) doesn't make the default emacs configuration a "modal editor" in any sense of which people actually apply those terms.
By your definition of modal, almost every application can be described this way. The point is not whether a system has modes, it's whether it makes its core emphasis and interaction modal.
You can see vi's motions as elegant and purposeful. I see them as an accident of history stemming from the poverty of the number of keys and capabilities of the dumb terminal it was designed on.
I encountered both editors in the late 80s and chose emacs precisely because it didn't have the "barely a step up from a teletype" interaction model that vi had.
As for Doom and Spacemacs without Evil.. yes... but why? Their original and state purpose was a packaging with a modal default. It's trivial to toss together your own init.el that brings in the same set of packages these days and with very little effort.
If the goal is an easy packaging of emacs with sensible defaults.. and then you have to go modify the defaults to make it what most people (yes, most) would consider sensible... No, that's not meeting the state use case.
Sure I do, and there's so much tacit knowledge that I can't ever explain verbally or in writing that goes into it, to the point that arguments like yours, challenging my "choices" would ever feel less disingenuous. It's like forcing a left-handed kid to hold the pen "correctly", due to religious dogmas. It just works far more naturally for me and thousands of other people, and just because you don't get it, it doesn't make the model useless. Try to see the other side, sometimes "dumb" ideas do work, and shit that works maybe ain't that stupid.
> Doom and Spacemacs without Evil.. yes... but why
Great question. Now maybe you're trying to learn something despite of "years of the opposite experience" feeding to your hubris. Doom offers a set of Lisp macros that come very handy - map!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, etc. - they genuinely can slash the inevitable boilerplate in the config. It's much easier to experiment with advising and instead then writing ad-remove-advice with different syntax, repeating the symbol names, etc., you'd simply prepend `un` to the form and eval it. add-hook! allows binding multiple fns to multiple hooks. And these are just some examples.
Also Doom does some tricks to make the startup blazing fast. Many times I have compared my config (that pulls over 350 packages) with someone else's vanilla. Doom demonstrably starts much faster.
It won't be a perfect transition, but it will make it a lot smoother.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
> I don't fully understand the editor
Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.
> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature
That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.
I have cua-mode and don't show startup message. What else do I need to modernize Emacs?
Plus now agent integration (aka GPTEL)
`treesitter` grammars _are_ easy to install.
`eglot` is available OOTB, `lsp-mode` is easy to install and configure if you prefer.
`gptel` is easy to install and configure.
I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.
Apart from that, I don't have a lot I insist on, and my used emacs package space keeps shrinking.
That said lately I use lem more than I do GNU emacs.
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
Grooming a personal .emacs or .vimrc is fine if you're working alone, but when you're on a team of professionals working on an application built on a commercial platform, a standard workflow for development is essential and an IDE supplies all the tools, integrations, and conventions to cover the basics of such a standard. Do not underestimate their value.
But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.
Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.
Thank you! No more:
(defun cutregion-or-killword (beginning end) "Kills region if marked else backward kills word." (interactive "r") (if (use-region-p) (kill-region beginning end) (backward-kill-word 1)))
(global-set-key (kbd "C-w") 'cutregion-or-killword)
I don't care what tools other developers use but in January I made my two dev Macs 'VSCode free' and use Emacs for everything. Feels better!
For decades I would spend tons of time experimenting with my Emacs setups but in the last few years I have been shifting to more out of the box experiences. I did write my own agentic coding platform in Emacs Lisp but I keep that separate from .emacs and .emacs.d
Someone should write an Emacs guide for people who haven't meaningfully touched their .emacs since the early 2000s
Should I consider adding tree-sitter into the mix?
Hallelujah and thank you, sweet little baby Jesus. Now I can get rid of this bullshit from my dotfiles:
rm -rf ~/.emacs.d/tree-sitter
mkdir -p ~/.emacs.d/tree-sitter
set _plat = windows
if ( `uname` == Linux ) set _plat = linux
if ( `uname` == Darwin ) set _plat = apple
set _arch = x86
if ( `arch` == arm64) set _arch = aarch64
gh release -R emacs-tree-sitter/tree-sitter-langs download -p "*${_arch}*${_plat}*"
tar -C ~/.emacs.d/tree-sitter --transform 's/^\(.*\.\(so\|dylib\|dll\)\)/libtree-sitter-\1/' -xzf tree-sitter-grammars*.tar.gz
rm tree-sitter-grammars*.tar.gz
although the brief time I used Magit I was enamored I gotta say. I tried lazygit recently and it evoked the same feeling I had when trying Magit for the first time
I have to use the pgtk channel, because Wayland.
pgtk/stable is 30.2, pgtk/edge is 32.0.50. Version 31 is not even offered on snap, in none of the channels. I am running on edge (32.0.50) with no problems.
I'd like to, but there is currently a RAM shortage
[j_jonah_jameson_laughing.mp4]
I use emacs --daemon instead of tmux inside my agent sandbox for session permanence and portability. A full editor rather than a layer between me and my editor. I can even waypipe the client windows if I want mouse support.
There's a bajillion ways to do this, some might even involve writing an html file and launching a remote server and tunneling and using a browser and what not. But no! ChatGPT wrote 20 lines of elisp code. I add a tramp basepath, open the text file, and got exactly what I needed. Need any behavior changes, callbacks, transformations? Modify, eval expression, new behavior!
I asked ChatGPT what other system I can use to achieve the same effect. The best answer it gave was neovim. No, neovim can't do that with the same degree of ease.
Disappointing and amazing at the same time.
The drawback of the emacs approach in my case is the tramp latency. To speed things up we'd want to add prefetch and that's gonna be much more than 20 lines and C-x e
Even if you didn't have emacs, I don't think you are forced to use VSCode. You could just use sshfs and use any local editor, but I guess other editors also have remote editing plugins
Please, if you have something to do with Emacs, can you review this for NetBSD and OpenBSD when using gtk3:
https://www.unitedbsd.com/d/1621-emacs-30-wxaw
The issue was traced to library xinput2, when compiled with '--without-xinput2' the issue does not occur. But I do not know if that is something that Emacs can address.
Open source with profanity in comments is statistically better than code without it:
https://blog.desdelinux.net/en/open-source-with-profanity-in...
https://news.ycombinator.com/item?id=36621699
DonHopkins on July 6, 2023 | parent | context | favorite | on: Open source code with profanity in comments is sta...
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
https://opensource.apple.com/source/emacs/emacs-59.0.80/emac...
1990-08-26 Richard Stallman (rms@mole.ai.mit.edu)
* terminal.el: Move possibly offensive comments to term-nasty.el.
https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
[...]
;; disgusting unix-required shit
;; Are we living twenty years in the past yet?
(defun te-losing-unix ()
nil) ;; (A version of the following comment which might be distractingly offensive
;; to some readers has been moved to term-nasty.el.)
;; unix lacks ITS-style tty control...
(defun te-process-output (preemptable)
;;>> There seems no good reason to ever disallow preemption
(setq preemptable t)
;; I suppose if I split the guts of this out into a separate
;; function we could trivially emulate different terminals
;; Who cares in any case? (Apart from stupid losers using rlogin)
(?\C-b . te-backward-char)
;; should be C-d, but un*x
;; pty's won't send \004 through!
;; Can you believe this?
;; Did I ask to be sent these characters?
;; I don't remember doing so, either.
;; (Perhaps some operating system or
;; other is completely incompetent...)
;;-- Not-widely-known (ie nonstandard) flags, which mean
;; o writing in the last column of the last line
;; doesn't cause idiotic scrolling, and
;; o don't use idiotische c-s/c-q sogenannte
;; ``flow control'' auf keinen Fall.
"LP:NF:"
;;-- For stupid or obsolete programs
"ic=^p_!:dc=^pd!:al=^p^o!:dl=^p^k!:ho=^p= :"
;;-- For disgusting programs.
;; (VI? What losers need these, I wonder?)
"im=:ei=:dm=:ed=:mi:do=^p^j:nl=^p^j:bs:")))
(setq te-process
(start-process "terminal-emulator" (current-buffer)
"/bin/sh" "-c"
;; Yuck!!! Start a shell to set some terminal
;; control characteristics. Then start the
;; "env" program to setup the terminal type
;; Then finally start the program we wanted.
(format "%s; exec %s"
te-stty-string
(mapconcat 'te-quote-arg-for-sh
(cons program args) " ")))))
;;;; what a complete loss
https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
;;; term-nasty.el --- Damned Things from terminfo.el
;;; This file is in the public domain, and was written by Stallman and Mlynarik
;;; Commentary:
;; Some people used to be bothered by the following comments that were
;; found in terminal.el. We decided they were distracting, and that it
;; was better not to have them there. On the other hand, we didn't want
;; to appear to be giving in to the pressure to censor obscenity that
;; currently threatens freedom of speech and of the press in the US.
;; So we decided to put the comments here.
;;; Code:
These comments were removed from te-losing-unix.
;(what lossage)
;(message "fucking-unix: %d" char)
This was before te-process-output.
;; fucking unix has -such- braindamaged lack of tty control...
And about the need to handle output characters such as C-m, C-g, C-h
and C-i even though the termcap doesn't say they may be used:
;fuck me harder
;again and again!
;wa12id!!
;(spiked)
;;; term-nasty.el ends here
Jamie Zawinski kept Lucid Emacs nasty:
https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
Noah Friedman, Aug 3, 1992, 4:54:20 AM
In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess) writes:
>In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu (Noah Friedman) writes:
>>It's by no means necessary, but it's funny.
>Along the same lines, look at lisp/terminal.el
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski