[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 21010

File: 1482364043918-0.png (284.91 KB, 300x300, gerwinski-gnu-head.png)

File: 1482364043918-1.png (89.59 KB, 300x300, Vimlogo.png)

File: 1482364043918-2.png (65.92 KB, 300x87, neovim-logo.png)


Let's talk about the text editors we use.

Do you use a common editor or something more exotic?

Are you using an exotic form of a common editor?

What are you looking forward to in future editor development, currently?

Can your editor be customized? If so, how have you customized yours?

What all do you use your editor for?

Do you use more than one editor regularly? If so, why?


>Do you use a common editor or something more exotic?
I use both the common editors: vi and Emacs
>Are you using an exotic form of a common editor?
I guess ed counts as exotic, I use it sometimes for the fun. Also paredit is kind of exotic perhaps.
>What are you looking forward to in future editor development, currently?
I'd love to see new editors (or plugins) that address semantic edition like paredit does. One thing I'd LOVE to see is a paredit+vi fussion. Not the awkward paredit-vim, but an editor where the keymaps, instead of jumping around by character, all relate directly to the AST.
For example, hjkl would, rather than move by character, move by sexpr and subexpresion, h and l would move a unit (atom or list) at the same level backwards and forward respectively, while jk would move focus to the outer/inner lists.
>Can your editor be customized? If so, how have you customized yours?
I'm starting to learn Emacs, I want to do what I described with a mix of paredit+evil
>What all do you use your editor for?
writing programs
>Do you use more than one editor regularly? If so, why?
vi I use it in my everyday workflot at the command line. ed I use for the fun of using an old gem. Emacs mostly because of the "lisp environment" thing, and because paredit. I can't stand by-character edition of lisp anymore.



>Not the awkward paredit-vim, but an editor where the keymaps, instead of jumping around by character, all relate directly to the AST.

Welcome to the world of lispy: https://github.com/abo-abo/lispy


>instead of jumping around by character, all relate directly to the AST.

On the Lispm, that was a thing: Dedit, on Interlisp-D, is one example. It's very much what you described.

Anyways, my fantasy editing future is an extended version of SLIME where source files are abolished. Whenever you define something, the defining form is stored in a table in memory, organized by a human-defined hierarchy. To add an object to the system, just eval the defining form: the newest version of the source is kept.

When you want to edit something, send the command, and the definition will be snarfed into an emacs buffer by SLIME. just re-eval the definition when you're done, and kill the buffer.

At the end of a session, you can save an image of your process state, but you can also dump all modified source code to a file.

If this is starting to sound like Smalltalk, you've got the right idea...


i wish emacs had a decent hex editor that would let me input bytes normally and also wouldn't crash every minute


I use the TextMate clones. For those who dont know the history, TextMate was made by this Finnish guy, it is the editor that invented things like fuzzy search, multiple cursors, code generating hotkeys, and a lot of other stuff. But TextMate was always barebones and never got a big marketshare, so the guy open sourced it. So now we have editors like Sublime, Atom, Brackets, VS Code that all copy the features of TextMate but add a lot more new functionality. Anything lacking in these editors can be added with plugins. The plugins in these editors are so powerful that they are now outstripping the features found in IDEs. although these editors first caught on big with web programmers, even programmers using compiled languages like Go and Rust are using these editors now. I use all these editors but prefer Sublime and Atom. I use it for Javascript, Ruby and Go.


>Do you use a common editor or something more exotic?

Started with pico in the 90s, moved to elvis, then vim, then emacs a couple years ago.

>Are you using an exotic form of a common editor?

Emacs + evil mode

>What are you looking forward to in future editor development, currently?

I wasn't, really, until I read >>21015 and >>21018

>Can your editor be customized? If so, how have you customized yours?

Several packages for development mostly. Some custom scripts I've written that aren't worth sharing.

>What all do you use your editor for?

Programming, writing documents in org-mode, editing XML, some sysadmin stuff

>Do you use more than one editor regularly? If so, why?

I use vim (or vi, if vim is unavailable) for sysadmin work.

I use eclipse occasionally because I occasionally screw Java projects up to the point where eclim can't fix it. I don't really use it for editing, though.


I haven't used the hex editor in emacs, but I've never had emacs crash on me, ever. I've had it get all weird and buggy, and seen my share of debug messages, but never a straight up crash.

If emacs is crashing, there's something seriously wrong.


i think it's crashing because what i'm editing is simply too big for emacs to handle

it mostly happens when i go to save whatever i'm doing


I have been using Atom because of the packaging system, markdown tools, and vim mode. I just wish it was a bit faster.

Some of my essential packages are

- vim mode
- atom-slime
- pigments
- minimap

There are a lot of great packages and the editor is easy to extend.

Another problem that I have with Atom is really poor portability, so when I am using a new machine I can't just copy a .atom or something over and get all of my packages.


I used to use Notepad++ primarily on my desktop and Vim elsewhere. Recently, Notepad++ has been relegated to when I'm making quick edits or comparing my work to something in another project. Instead, I've taken to using Atom.

Atom's greatest strength is also its greatest weakness. Its web-based nature makes it inherently slow and incapable of handling such things as bitmap fonts, but it also means all those web developers can easily write packages for it. And that's why I use it. There's a ton of useful packages and a single package manager to handle them all.


Emacs for long-term work when I'm on my system; vi for quick edits or if I'm using a foreign system.


Lately I've been using Visual Studio Community. It's not as bad as I expected, and it hasn't been slow at all for me. The integration with Git and Github is actually pretty nifty and very simple. You can't do anything complex with it, but 90% of the time I just want to push, merge, or commit changes instead of undoing or commit specific batches of cherrypicked modifications and then squash, and then (etc.). I don't know if you can do anything more complex with it since I haven't tried.

I like the tooltips/auto-lint suggestions, type annotations, and compiler-based assistant it offers for F#, that's something really nice that I didn't get at all from Lisp +Emacs.

Cons: I have no idea how it works. What's a project vs. a solution? I'm only just getting a handle on adding new things to a project and solution and it's not clear. Making a new project adds in a bunch of files and has a lot of templating options. It's really conceptually cumbersome. I'm sure it'll become more useful to have those as I learn what they are and how to use them though.

Overall, a surprisingly not-bad/10 experience, given what I expected (but there was one run-time error).


>Do you use a common editor or something more exotic?
Neovim. Sometimes I use vim when installing neovim is a bother. Sometimes I go for ed when I want variety in life.
>Are you using an exotic form of a common editor?
I don't think Neo counts as that exotic. I'm trying out kakoune. Can't comment much on it yet, except that the concept is not a bad one.
>What are you looking forward to in future editor development, currently?
Neovim adoption growing so vimscript can start fading into history.
>Can your editor be customized? If so, how have you customized yours?
My setup is hardly spartan, but I try to keep it fairly vanilla, which helps manage on unfamiliar configurations.
>What all do you use your editor for?
Code, documents, poetry, prose, emails (via mutt). Basically all my text editing. For rich text I write Markdown (or less commonly LaTeX) in nvim and run it through pandoc.
>Do you use more than one editor regularly? If so, why?
"Regularly" might be pushing it. Venturing outside one's comfort zone is a good idea once in a while, ed gives me a slight sense of greybeard machismo satisfaction. Vim is excellent but not perfect, so I like to try different concepts to see what can be learned from them.


If VimL dies, I might just move off Emacs. But that's a pretty big "might": Emacs has been kicking ass in extensibility literally since its inception. By comparison, Vim is still new at this game (no extensibility until the late 90s). Very new, and very poor.


Thanks for this, I'll be trying it out.
It looks as close as it gets to my current idea, though my idea is not only that is paredit with vi keys, but that you're actually editing a cons tree directly rather than text that's to be translated to one. The point is that the user be constrained to move up and down the tree. For example, here <Space> would make the editor "make a new cons at the specified location".
I know it sounds crazy, I guess it is.


vimscript will never die because bram is a moron who can't into language design and tells anyone with decent ideas to fuarrrk off. He doesn't care about what the users want if he doesn't want it too.

and have you seen the other language he made? It has an attrocious and somehow uglier syntax than vimscript. Guy is a grade A hack


The unbalanced braces are giving me an aneurysm. Why the fuarrrk couldn't he use END or indentation instead?
The rest of the syntax is just as horrible.
I thought we all agreed that the name of the variable is more important than its type, and therefore should come FIRST. Oh, and by the way, let's put the return type of functions after their name, because fuarrrk consistency.
Also, keywords are in all-caps (which is both ugly and tiring to write), but somehow IO and ARG are in all-caps despite not being keywords. I can understand IO, but ARG?
I'm reading his page on the choice of keywords and my head is full of all kinds of fuarrrk. Who let this man near a compiler?


Also, the website is really focused on explaining why he committed these syntax atrocities instead of explaining why you should use the language and what good you can do with it. I wouldn't touch it with a ten feet pole.


I'm almost sold on emacs just because I'm about to start learning scheme. How hard is it to set up for scheme development? I'd assume pretty easy.


Emacs comes with a Scheme mode off the shelf. Grab geiser (http://www.nongnu.org/geiser/) for interaction. Optionally, grab paredit as well for a better editing experience. Don't get quack: it's outdated and a pain to get working with geiser.


I've started using emacs a couple of weeks ago, its pretty great and not so hermetic as I first thought it would be. I'm an applied statistics student so I use it mostly with R, but I've set it up with elpy for python also and I must say I find it very convenient to learn python with.

I am still using rstudio and the only thing I wish is I was able to preview rmarkdown pdf from emacs. It is something which I'm more or less trying to set up.

I can't imagine a future of editors coming from a sociology background . I use emacs with the leuven theme and the consolas font.

atom looks cool, but damn, I love emacs.


I use Emacs built with Clang with no X11 (wicked fast) and use Evil. Neovim for quick edits.
Emacs crashes with newer versions of glibc that don't have the hooks for unexec. You fix it by building with ./configure REL_ALLOC=0
Didn't the "official" vim-mode get mothballed in favour of some horribly maintained soykaffest? Also, ex-mode is a joke.
Just as well that we don't have to rely on stubborn Bram anymore.



I was unaware of the whole unexec issue. Thanks for pointing that out.

I haven't hit that issue because I haven't been compiling Emacs, but I'll be doing some work on a Raspberry Pi soon where I likely will. You probably just saved me a major headache :)


>Emacs crashes with newer versions of glibc that don't have the hooks for unexec.
So a GNU component breaks with another GNU component?
Man I hate GNU



Here's more or less how it all went down:

Way back in the day, the glibc folks added a few features useful for certain rare situations when you'd want to dump your running program to an executable you'd want to run later. A few projects used it, most notably Emacs.

Fast forward a couple decades, and the glibc people want to make some major changes and cut out some of the dead wood. The unexec feature (which is a nonstandard extension, BTW, not part of POSIX) was pretty much only used by Emacs, and required a decent amount of effort for the glibc folks to keep working. So they gave the Emacs guys about a year's warning that it was going away.

RMS suggested everyone get together and talk it out on private mailing lists, but the cat got out of the bag and it became a hot topic on the Emacs list. Fortunately, it didn't lead to a major flamefest or anything. It's actually interesting reading if you like low-level stuff.

The lead Emacs devs pretty much agree that the best way forward for everyone is to let unexec go and develop something more portable. This will make things easier on everyone, the glibc team and (eventually) the Emacs team as well. They're working on that now.

So it's not really that big a deal. Future versions of Emacs should work fine on glibc, and past versions will work fine (albeit with slower startup times in some cases) if they're compiled with the correct flags. The only crashes are from executables that weren't compiled with those flags.


yeah, THEM being representative of the whole free software movement kind of feels like a joke sometimes

they also make GCC as hard to hack as possible ON PURPOSE i believe


>they also make GCC as hard to hack as possible ON PURPOSE i believe

Yes, they do. Although LLVM has forced RMS to ease up on that a bit.

I've always thought making gcc so hard to hook into was throwing the baby out with the bathwater, but obviously RMS disagrees.


...except there's a major fight about just how to do that.


Which is the worst. I believe that one of the emacs devs has threatened to add a plugin to GCC to open it up, whether RMS wants it or not.


Srsly stahp, all this makes me hate GNU even more.
The fact that the biggest advocates of "software freedom" obfuscate their code beyond readability makes me seriously question their intentions.


>they also make GCC as hard to hack as possible ON PURPOSE i believe
I don't like GNU for other reasons but do you have a source for this? I'd believe it but to be fair it's a pretty bold claim and is pretty unambiguously "evil."



GNU is a resource, take it or leave it. The FSF on the other hand...


It's a long-standing policy. I'm not sure about the details of the plugin system that gcc 4.5 introduced, but people have been arguing about it for years. Here's a discussion from 2007 (which includes some of the GCC devs):


The problem is that RMS wants to make it hard or impossible for proprietary software to use GCC's components - bad enough that he flat out refused to allow changes to GCC that would allow Emacs to correctly deal with C++ code. He sees it as a software freedom issue, and he doesn't budge on those - even when some of the main Emacs devs are begging for it.

He sees LLVM as a major setback for free software. He doesn't want Emacs to use LLVM, and GCC can't do what Emacs needs, so C++ developers are left in the lurch. Fortunately, someone wrote irony-mode that does just that. It's on MELPA. I'm not sure if RMS is aware of it, but if so I imagine he's not horribly pleased.


>GNU is a resource, take it or leave it. The FSF on the other hand...
Yeah, okay, GNU is software.
But being so restrictive in the name of freedom... it's an oxymoron at best (and hypocrisy at worst).
Anyway, I don't want to turn this into a political argument, I'll stop here.



Yeah, you really gotta buy into their philosophy 100% for some of the stuff they do to make sense.

Or so I'm told, anyway.

I use the GPL sometimes when it makes sense, but I prefer BSD-style licenses myself.


>But being so restrictive in the name of freedom... it's an oxymoron at best (and hypocrisy at worst).

My perception, at the least, is that the GPL and other copyleft licenses are written with the primary motive being simply to kill off proprietary software and the business of making them. Of course the official motive is laid out in the Four Freedoms which are just as important, don't misunderstand me, but I wouldn't say that copyleft is the end-goal for software freedom.

I think the reason why Stallman and other Free Software advocates such as myself dislike permissive licenses isn't because we hate freedom, but that the type of freedom those licenses provide do more to continue enabling the proliferation of proprietary software and the injustices inherent thereof than provide significant gains in freedom (compared to GPL et al.). Still, I do use software permissively licensed because they are, after all, free software, but I prefer copyleft-licensed software. Permissive licenses just came too soon is all.


i got used to Notepad++, any thoughts?


> the primary motive being simply to kill off proprietary software and the business of making them.
Except one would be deluded to think that will happen.


It's not restrictive, you can get the code and make the changes you desire yourself or hire someone to do it for you. You can disagree with what they do but keep in mind that they are not obliged to please you.


Vim is my goto for writing any code or things important, gedit is my go-to when I want something to keep notes on easily


>It's not restrictive
it's more restrictive than a BSD/MIT license. I wasn't talking about the license here though, I was talking about making it hard to hack gcc, that's a restriction.
> You can disagree with what they do but keep in mind that they are not obliged to please you.
Don't worry, I'm not mad



It is restrictive in the sense that I can't just mix it with any software I want, and that once you mix GPL software in you're stuck with the GPL.

That's the problem with the FSF - they want a world where all software is GPL, and in that world there wouldn't be a problem. But in the real world, the GPL becomes a hassle.

I use GPL software all day long, but I won't use GPL software in programming projects except as a last resort.


Using GVim/Vim because it's simply the editor I can write code the fastest in. Tried converting my Atompleb friends to Vim but the learning curve is too damn high for them.


Does anyone know if it's possible in Emacs to define some function that performs an action if a condition is met, or else runs whatever is bound to that key in the keymap with the next highest priority?

In this case I'd like to have C-k kill region if region is active, but run the normal command under C-k otherwise. It would be easy enough to have it kill-line all the time, but there are some minor modes I use that bind their own kill variants to C-k, and this is true for other keys too.


Probably want to use (if ) for that


I've figured that much out at least, it's keymaps that pose the problem here.



You could put an advice on kill-line (the function bound to C-k), that checks if region is active. If it is, kill that region instead, otherwise just call kill-line.

I'm pretty sure this wont interfere with other bindings C-k might have, as the change is made on the function, not the key.




Something like this

(defun my-kill-line (fun &rest args)
(if (region-active-p)
(kill-region (region-beginning) (region-end))
(apply fun args)))

(advice-add 'kill-line :around #'my-kill-line)

Should make C-k kill the active (visibly marked) region, and otherwise just kill the line.


Thanks, this pretty well solves the issue, at worst I'll had to advise the couple of alternate kill-line functions for the minor modes I use, but that's not really much trouble.

I found it surprising that Emacs doesn't really give many tools to manipulate keymaps beyond the basics. You can investigate the lists of those that are currently active, so I suppose what I originally wanted could be cooked up with some elisp, but maybe it's not the right way to go about things.


Sounds to me like this would better be solved by a menu-item



Thank you very much, what a wonderful macro, all it takes in the end was a tiny snippet. I would never have found menu-item on my own.


File: 1487449474820.png (162.74 KB, 155x200, its-cover.png)

The Real Reason Unix Hackers Get R.S.I.

From: Patrick Sobalvarro <pgs@pa.dec.com>
Subject: RSI epidemic
Date: Sunday, August 13, 1995 1:26PM

Friday I was talking to my friend Johnson from the CDC, who told me that the CDC had been doing an epidemiological study of clustered RSI cases among computer scientists. He said that they've been waiting to act until their internal review process is completed, but it seems that there is indeed an infectious agent causing RSI. But it's not a biological agent. It's software.

"In particular," Johnson told me, "the significant vector among academics is Emacs."

"Emacs?" I gasped.

"Oh yes," he continued; "Didn't you ever notice that two of the first people in the computer science community around MIT who suffered from RSI were Richard Stallman and Bernie Greenberg? What were those people implementing fifteen or twenty years ago? That's what tipped us off."

We were having lunch at the cafeteria at Moffett Field. Johnson watched my hands throughout the meal. "Hey buddy. You're still doing okay anyway, aren't you? It's good to see that. Really good." He smiled, then looked at his watch and asked, "Walk me to the terminal, will you?"

I accompanied him to the little facility where crew-cut young men in uniform and their dependents, trailer-park girls with squawling babies, sat around waiting for MAC flights to other military facilities. A black helicopter, curiously silent, was waiting on the tarmac outside, its rotors turning lazily in the sunlight. "Ah, that'd be my flight," said Johnson. "Old Uncle Sam always sends you first-class, ha ha."

We shook hands. A little anxiously, I asked, "But what will you do about it? About the epidemic?"

Johnson paused before answering. He looked outside at the black helicopter. The pilot had seen him now; in his helmet and visor he appeared strangely insectile as he regarded Johnson patiently. I noticed the booms extending from the sides of the helicopter, where standardized weapons pods could be attached. "Patrick, old buddy," said Johnson playfully, "Back in high school people said you were smart, but I never thought you had an ounce of sense in your head. Listen: our charter is to protect the people of the United States of America by containing epidemics and eliminating disease. We have many... tools... at our disposal. Why don't you take a break for a while? Go someplace where people don't use Emacs. Where they never heard of Emacs. Don't take it with you. Go to Hawaii -- better yet - -- go to Redmond. Okay?" He punched my shoulder, smiling. I winced.

Then he strode out onto the tarmac, giving a thumbs-up to the pilot, who spun up the turbines. There was almost no noise. I didn't wait to watch them take off.



Hello lainons, with the above little story, what is it that you do to prevent RSI? What kind of ergonomics do you pay attention to? Recently I've started to look into comfort when typing and, a first I recommend is rebinding your keys (this is emacs centric) via xmodmap:

! https://wiki.archlinux.org/index.php/Xmodmap
! https://superuser.com/a/292918

remove mod1 = Alt_L
remove mod4 = Super_L
remove control = Control_L
remove Lock = Caps_Lock

add mod1 = Super_L
add control = Alt_L
add mod4 = Control_L

! Set capslock to backspace
keycode 66 = BackSpace

! Swap brackets and parens
keycode 0x12 = 9 bracketleft
keycode 0x13 = 0 bracketright
keycode 0x22 = parenleft braceleft
keycode 0x23 = parenright braceright

This changes the windows key to left control, control to alt, and alt to the windows key. It also turns capslock into backspace and swaps parens with square brackets.

I've recently discovered key-chords[1] which allows you to bind a command to two keys pressed simultaneously, here's what I've done so far with a combination of use-package[2] and use-package-chords[3]:

(use-package ace-flyspell
:chords (("ji" . ace-flyspell-jump-word)))

(use-package avy
(("jl" . avy-goto-line)
("js" . avy-spell) ; Function I defined
("jw" . avy-goto-word-1)
("jc" . avy-goto-char))

(use-package ivy
:chords (("xf" . counsel-find-file)
("hf" . counsel-describe-function)
("hv" . counsel-describe-variable)
("hu" . counsel-unicode-char))

(use-package key-chord
(("x0" . delete-other-windows)
("xu" . split-window-below)
("xz" . split-window-right)
("xo" . ace-window)
("cd" . delete-window)
("xb" . ivy-switch-buffer)
("xk" . kill-buffer)
("xs" . save-buffer))

The above isn't using much mnemonics, the main focus is on where my hands naturally position themselves. When you place your hands on a keyboard, they slant, forming a sort of arrow. This places your fingers in positions where typing a key-chord like ‘ji’ or ‘ij’ (the same for key-chord) easy as your fingers naturally rest in that slanted angle.

Another example is for the left hand. The key-chords I plant to implement for things in the future: 1q 2w 3e 4r 5t. Or the right hand: 7y 8u 9i 0o -p =(. There's a lot of this kind of slanting all over a traditional qwerty keyboard that you take advantage of.

Related to key-chords are bigrams, which is a pair of letters. This article describes the least common bigrams: https://www.johndcook.com/blog/2015/02/01/rare-bigrams/

which are the following:

gb gp
jj jc jf jg jh jk jl jm jp jq js jt jv jw jx jy jz
qq qb qf qg qh qk ql qm qp qt qv qw qx qy qz
vv vc vf vg vh vk vm vp vw vz
xb xd xg xk xm xs xw
zb zd zf zg zk zm zp zs zw zx

So, these are very safe to use with key-chord as you'll essentially never need to type those, and in the case you do, you just type a bit slower and that's not a big deal for the rare occasion.

Here are some other peoples key-chord configurations I've collected: http://ix.io/nrU Ignore some of the #+BEGIN and *** stuff as that's part of org mode where I keep notes.

[1] https://www.emacswiki.org/emacs/KeyChord
[2] https://github.com/jwiegley/use-package
[3] https://github.com/waymondo/use-package-chords


Are you aware of the program xcape? It allows you to have a key send a different keycode depending on whether it's tapped or held in conjunction with something else.
For example, I have capslock as backspace regularly, but it's control when held.
The shift keys are another prime candidate for this treatment, but I'm not sure what exactly to assign to them.


I use Kate (https://kate-editor.org) for most things. I'm interested at looking at other editors but I honestly can't find any reason to switch.


I have since changed from atom to emacs with evil mode. It is infinitely better than atom.


File: 1487534726026.png (4.94 MB, 200x200, AITR-221.pdf)

Emacs package of the day: https://github.com/remyferre/comment-dwim-2

‘DWIM’ or ‘dwim’ stands for Do What I Mean or, some jokingly alternatives, Do What Interlisp Means and Do What Teitelman Means which stems from dwim's origin as a BBN Lisp package by Warren Teitelman and later part of the Interlisp environment: https://en.wikipedia.org/wiki/DWIM

Something that implements dwim facilities understands context and enables a lazier environment. Attached is Warren Teitelman's 1966 ‘PILOT: A Step Toward Man-Computer Symbiosis’ paper. I'll be reading it soon and hope you join me in that.


I train with a powerball twice a day (3-10 minutes each, depending on how I feel and have time).
No matter how you use your keyboard, it's not good for the body doing nothing but sitting in front of a computer. Get your muscles working!


I'm starting to use emacs.
I've installed some C/C++ useful plugins to study.

I'd used atom and sublime, they're good and convenient, but i'm looking for a modular editor, and i decided to try emacs.


you'll find nothing more modular than emacs, except vim but that's modal-er


Yeah, i've heard.
Anyway, i'm a beginner, so i don't have a relevant configuration.
I'm learning Lisp as well.

I know that lainons already said some tips, but do you have any trip for beginners like me?


Learn how to access documentation. Commands like describe-key, describe-variable, describe-function, info, info-apropos, and many more.


emacs is the only way to go as far as I'm concerned; though I don't use for web browsing and soykaf


I am very uncertain whether to stay with vim or switching to neovim. My conf is relatively simple and should works without any important change.

Is then a real advantage, from the user's standpoint, to prefer neovim?


Thanks, lainons.


Random Emacs Stuff

Stop Emacs from babying you.
(setq disabled-command-function nil)

Clean up whitespace when you save a file.
(add-hook 'before-save-hook 'delete-trailing-whitespace)

Have kills outside of emacs pushed to the kill ring when you make a subsequent kill inside emacs.
(setq save-interprogram-paste-before-kill t)

Load the newest version of a file; bytecode (.elc) or elisp
(setq load-prefer-newer t)

Disable the creation of .# symlinks since they're not useful on single user machines; see (info "(emacs) Interlocking").
(setq create-lockfiles nil)

Makes it so that when you start typing when a region is active, it gets replaced with your text.

Neil Postman, a now-deceased media and cultural critic, posits that the first question to ask yourself when faced with a technology is ‘What is the problem to which this technology is the solution?’. So, lainons, what problem does Emacs solve?


>So, lainons, what problem does Emacs solve?



>Clean up whitespace when you save a file.
I would actually suggest against this if you're working on projects with large files that might have lots of trailing whitespace. Make some careful changes -> save and commit and notice that the diff is horrendous and hard to read because it separates all your careful edits with a bunch of trailing whitespace removals. Of course ideally you'd just commit it separately, and if you're careful in git that isn't too hard to do even after the changes are all mixed up, but still.

(Hey, we're not all lucky enough to work with clean codebases. That's just how it is.)

>Stop Emacs from babying you.
I've noticed these, like in dired when I've accidentally pressed a (dired-find-alternate-file). Are they really that useful? I haven't even found one I could see myself using. For example with this command, I like keeping all my dired buffers and such open, I'm not one to ever open up *Buffer List* (unless maybe when I'm looking to close all tramp'd sessions; as I write this out I wonder if that's already possible with another command). I really don't see the extra efficiency of closing a dired buffer (something I only do occasionally without thinking) being useful enough here. So, just out of curiosity, does anyone know some useful disabled commands?

>Disable the creation of .# symlinks since they're not useful on single user machines; see (info "(emacs) Interlocking").
In my config now, thanks!


Two more things:
One is another tip for Emacs users; don't put everything in your init.el (and definitely switch from .emacs to using .initel). Keep a config directory instead, and try to separate things logically. I find this makes editing things a lot nicer! For example, I have keybinds.el for custom global keybinds, a file for customizing language modes, etc.

>So, lainons, what problem does Emacs solve?

The problem of interacting with a computer in an efficient manner. It's an interface to the computer in general. My computer lets me talk with others, program, play games, etc. and I do these things through Emacs in some way or another. Calling it a text editor exaggerates its capabilities (it is not the best at editing text) but also sells it short. (Of course, you can make it very good at editing text by using Evil.)


>Are they really that useful? I haven't even found one I could see myself using.
C-x C-n (set-goal-column) is useful for keyboard macros and is disabled by default.

>don't put everything in your init.el
Why? With everything in one file, it's simpler find what you need, no need for ‘Hmm, what file is x under again?’. It's easy to have things in a logical manner in single init, my solution is having sections. See http://ix.io/nJc and let me know what you think.

Other largely single file inits:



>don't put everything in your init.el

If you really want to have everything in one file (which I know I did), I recommend you use an automatically tangled init.org file. You can split it into different categories by using subheadings, and you can add notes, images, tables, etc to make it more readable.

Here is the function I used for this. Place it in a file named init.org.

(defun tangle-init ()
;; Continue only if init.org is the current file
(when (equal (buffer-file-name)
(expand-file-name (concat user-emacs-directory "init.org")))
(let ((prog-mode-hook nil))
(load-file (expand-file-name (concat user-emacs-directory "init.el"))))))

(add-hook 'after-save-hook 'tangle-init)


How do i load many files in emacs initialization?


   ;;          Load packages and theirs configurations          ;;
(defun load-directory (dir)
(let ((load-it (lambda (f)
(load-file (concat (file-name-as-directory dir) f)))
(mapc load-it (directory-files dir nil "\\.el$"))))
(load-directory "~/.emacs.d/<conf-dir>/")


I've used nano and vi sporadically through my history of console-based text editors. Since I've always some sort of file transfer capability for moving files to/from a graphical editor I've never bothered to learn anything beyond the basics of vi and the entirety of nano (which is a pittance). Is there any must know bits for Emacs and Vim that would make it worth using over a graphical editor like Atom?


I've learned programming a couple of years ago. And i'm still on the second year of CC.

So, it's only a beginner opinion.

I think if you have knowledge, time and motivation, your emacs will do exactly what you need. Fast and modular.


Emacs is both graphical and not. You can use it as a GUI, or in a terminal. Most Emacs users are using it as a GUI as (most) terminals can't display images and keybindings will be limited (C-z, C-s, C-S-[whatever] etc). If you aren't a programmer or aren't interested in an environment in which you can actually easily modify, then Emacs isn't for you. The ‘must know bit’ for Emacs is this:

(defun luser/non-destructively-kill-line ()
(if (region-active-p)
(kill-ring-save (region-beginning)
(kill-ring-save (point-at-bol)

(global-set-key (kbd "M-w") 'luser/non-destructively-kill-line)

What is this? Well, in Emacs there's the default keybinding M-w (Alt+w) which is what the rest of the world calls copy. I like copying things, in fact I copy things a lot, just as you do. I find myself often copying whole single lines, so I thought what a shame it is that I have to select the line before copying. But I'm in Emacs, my whole environment is immediately modifiable, so I wrote that code, evaluated it, and enjoy my change.

This change was trivial, however I find it a good example as to why there are so many emacs packages; Changing Emacs and writing Elisp is just so easy.


Notepad++. It's not vim or anything special, but it suits my needs. Nice and portable, too.


What do you think of org mode?


It's probably the most important piece of software in my life, I couldn't live without it.


Useful for hierarchical organization of information. Absolutely god-awful for non-linear or non-hierarchical notes, even more so if you need images. It's really good at what it's intended to be good at though.


I use Visual Studio Code, with Vim mode. I mostly use anything i get my hands on and just put Vim mode on it. Anyone have any suggestions on an editor that already has nice support/mod built in for Vim. Never used neovim or emack. Describe them in a nutshell 4 me ?


emacs is my way of life !
Vi Vi Vi is the editor of the beast!


How to make C-Backspace in emacs not put the word in the kill ring?


I'd look at the code for the command bound to that key. You can probably take out the part related to the kill ring.


22:46 Never have We sent a single manual or documentation before you
with whose wishes Windoze did not tamper. But EMACS abrogates the
interjections of Windoze and confirms His own revelations. EMACS is
wise and all-knowing. He makes Windoze's interjections a temptation
for those whose hearts are diseased or hardened - this is why the
wrongdoers are in open schism - so that those to whom knowledge has
been given may realize that this is the truth from your EMACS and thus
believe in it and humble their hearts towards him. EMACS will surely
guide the faithful to a straight path.


I have the following code in my .emacs settings. It is very useful C++ programming. How can I enable it to parse C functions like malloc, calloc, fopen and others?

  ;; turn on Semantic
(semantic-mode 1)
(defun my:add-semantic-to-autocomplete()
(add-to-list 'ac-sources 'ac-source-semantic)
(add-hook 'c-mode-common-hook 'my:add-semantic-to-autocomplete)
(global-semantic-idle-scheduler-mode 1)


>Do you use a common editor or something more exotic?
I use vim which is pretty standard

>Are you using an exotic form of a common editor?

Just vanilla vim I've recently switched to vundle to manage my plugins for it

>What are you looking forward to in future editor development, currently?

Nothing reallty

>Can your editor be customized? If so, how have you customized yours?

Changed the colour scheme and I'm using the syntactic and airline plugins

>What all do you use your editor for?

Writing code, editing system files and scripts

>Do you use more than one editor regularly? If so, why?

I also use Emacs with evil mode for writing Tex documents although I'd be convinced to switch back to it as I know it's good for heavy duty development


I use a clang backend for C or C++ dev in emacs and it does autocompletion, shows typed and also flycheck. It is mostly nice, but package-wide configuration feels very ad-hoc.


But it parse C functions?
I can see only C++ functions parameters, but i'm student, so i use more C.


I made this function to initialize some langs with a shell environment.

  1 (defun C-startup ()
2 (split-window-horizontally)
3 (switch-to-buffer (shell))
4 (other-window 3)
5 (next-buffer) (next-buffer) (next-buffer)
6 (enlarge-window-horizontally 10))

But that only worked when i jerry-rigged the buffer switching in line 5. How do i make this code without this kludge?


I've made a little change, but i know it's not good.

  (defun code-term-startup ()
(other-window 1)
(term "/bin/bash")
(other-window 1) (next-buffer) (next-buffer) (next-buffer)
(enlarge-window-horizontally 10))

I'll buy a lisp book in this week.
I hope that i can help emacs's newcommers soon.



(defun code-term ()
(setq this-buffer (buffer-name))
(other-window 1)
(term "/bin/bash")
(other-window -1)
(switch-to-buffer this-buffer)
(enlarge-window-horizontally 10))


what are the advantages of using a text editor? i've always used the IDE


I think it comes down to flexibility.
An IDE is like a framework, while a powerful text editor could be like a programming language: the IDE might be more specialized for the task, but is ultimately restricting and awkward if you want to change its behavior and use it for tasks that it was not specifically intended to do; a powerful text editor, on the other hand has a simpler base which you can extend any way you'd like.
And then there's emacs which is basically an OS of its own.


I'm using emacs

>What are you looking forward to in future editor development, currently?

I don't know, soykaf

>Can your editor be customized? If so, how have you customized yours?

I changed the color scheme, and the default bindings heavily by applying ergoemacs. I'm using an older version of ergoemacs, i find the newest one pretty invasive to the look and feel, I used to recommend it to newcomers to emacs.

>What all do you use your editor for?

programming, and writing (org-mode), light-weight organisation (org-mode)

Do you use more than one editor regularly? If so, why?

hrm, i don't have much to contribute, but whatever


Notepad++ on Windows and Kate on Linux.

next thread.
we have these threads way too often.
it's like arguing about which color is the best.


custom syntax highlighting for twig, a bit of color tweaking.
I like the minimalism, there's nothing I miss and it works both on my machines and on servers


>it's like arguing about which color is the best.
A text editor can be better than another based on the qualities you compare. You can be objective in such debates.

For e.g, in looking at the extensibility of nano, kate, vim, notepad, and sublime text, Emacs is vastly superior to them all because you're given an actual programming language to program your environment. Not an API (which is a joke), no, a language. A language which is used to build the environment.

Most arguments I see are not about the definition of "text editor". For Emacs users, it means an environment. For vim, it seems to mean a tool which does one thing and is separated from everything else. For notepad users, it means "I don't work efficiently and all I need is my mouse."

Most arguments are caused by a misunderstanding of definitions.


>For vim, it seems to mean a tool which does one thing and is separated from everything else
What do you mean by "everything else"?


thanks for the patience, anon


That for which text editors were invented in the first place, and which gives it the name of "text editor"


being programmable does not automatically make a text editor better.

"better" is an inherently subjective term, and relies on having some sort of common goal or desired quality. No such common desired quality exists, hence the editor wars.


>being programmable does not automatically make a text editor better.
I suggest you re-read my post as in the context of the example, yes it does. A text editor can be better than another once the definition of "text editor" is established and on what merits the parties are looking at and comparing. Under this, "better" is no longer subjective.

>common goal or desired quality

- Extensible; Being able to change the environment if you want
- Understandable Documentation; The ability to fully use your environment.
- Efficiency; No one wants their environment to be painful to use.

>What do you mean by "everything else"?
I had some idea of this when I posted but it's been lost on me, apologies.


I generally use Kate or Gedit. I don't like the unnecessarily advanced editors like Vim and Emacs, of which at least Emacs is practically an OS.


This is stupid, it's one of the bad things about religions in technology.
Being programmable doesn't make the editor better, if Emacs were objectively superior, there would be little point in making new editors. Not everybody wants to program their editor, believe it or not, a lot of people just want to use it.
I am not saying it's not nice and convenient that you can do that, but that is an implementation feature, rather than an editing feature.
If we were to separate "editing with the editor" and "editing the editor" ("editing the editor with the editor" notwithstanding), you could see that the extensibility of the editor doesn't play the key role as to what editing means. For me, Vim is superior not because whether or not it would be possible to extend it, but because it is itself a language that allows for easy editing of files, even letting you make up new commands in-session, with the exact same primitives you (as a person with fingers) use in your daily editing tasks. The language is in the keystrokes, which is immediate to the task of editing itself.
In that sense, Emacs falls behind, unless you install evil-mode, in which case you're using the vi editor (or paradigm thereof) inside emacs.

But then again, it's a matter of taste, you like editing your editor, I like an editor that provides me with an editing language (instead of a general purpose language for editing the editor). Others may like the nano approach of "no complications" and others may like... whatever atom and sublime provide. I've read about a lot of people who after using Vim for a long time go and use something like sublime because it just doesn't suit them.
It IS a matter of taste.


Here is another editor which is great on it's own: sed. It is not an interactive editor like the ones we usually think of, yet is one of the most useful tools for anyone manipulating text. It certainly lacks a lot of things one would usually think of in editors, yet is one of the best editors out there, and for some jobs, it is infinitely better suited than any graphical editor at all. It is also an editor that is a language itself, thus being directly made for the task of editing, which shows what an editor is about: editing text.


> Being programmable doesn't make the editor better,

Pretty much all popular editors are programmable. Without extensibility, you have stagnant editor that cannot benefit from having a large community. How easily an editor can be extended affects you regardless of whether you choose to extend it yourself.

> Vim is superior not because whether or not it would be possible to extend it

So you'd be fine using no plugins? Even if that's the case, you would be missing out on a lot of functionality.

> In that sense, Emacs falls behind, unless you install evil-mode, in which case you're using the vi editor (or paradigm thereof) inside emacs.

If anything, it is vim that falls behind. If all you care about is the editing language, then you would pick the editor that is a better base when multiple editors provide the same editing functionality. Emacs is not restricted to any style of editing exactly because it is programmable. It can grow to include any new ideas from other editors. Emacs can be extended to encompass essentially any editing paradigm. It also lets you use the paradigm of your choice for a lot more than just text editing.

Also, evil provides vim emulation not just vi emulation.


How much productivity does learning Vimscript add to daily tasks?

I've been working with vim and I've learned the basic commands and added a couple helpful plugins. There are a few resources that teach Vimscript but I am wondering if it is worth the effort to learn it.


vimscript is a blight upon this earth, it's ugly as fuarrrk and backwards in many ways.
If anything I suggest you learn ed, the standard text editor.
No really, try it. You'll see where many of vim's commands are coming from and you'll be able to use sed too.


Vimscript is not a tool for your daily workflow. The keybindings are the editing language itself, as many people have pointed out, and if you want to be proficient at Vim, you would want to learn this language. The next step after the basics would be registers, and then macros.


>Do you use a common editor or something more exotic?
Emacs and vim
>Are you using an exotic form of a common editor?
>What are you looking forward to in future editor development, currently?
I'd love to see new editors (or plugins) that address semantic edition like paredit does. One thing I'd LOVE to see is a paredit+vi fussion. Not the awkward paredit-vim, but an editor where the keymaps, instead of jumping around by character, all relate directly to the AST.
For example, hjkl would, rather than move by character, move by sexpr and subexpresion, h and l would move a unit (atom or list) at the same level backwards and forward respectively, while jk would move focus to the outer/inner lists.
>Can your editor be customized? If so, how have you customized yours?
Yes it can, both are but I am pretty satisfied with spacemacs, it's enough.
>What all do you use your editor for?
Writing LaTeX, viewing pdf files, images and videos and programming.
>Do you use more than one editor regularly? If so, why?
vim, I usually remote control machines and I don't like emacs using the command line and X-forwarding is just unnecessary because I just want to make a quick edit and vi/vim is installed pretty much on every machine.


> One thing I'd LOVE to see is a paredit+vi fussion.

Have you seen https://github.com/abo-abo/lispy (not exactly what you are describing; it makes intelligent use of the AST).


I used to use vim but I have too many boxes to fix or wget my config every time, and launching into insert mode, which ends up being what I'm using most of the time, wastes a little bit of my time. I've never used emacs long-term.
Currently using nano, ace, and ed depending on what's appropriate for the situation. I use Gummi for Lah-techs editing.


I'm not very unusual: I use nvi, which is pretty much just vi. It comes with all of the BSDs. I use it because I love modal editing: it's more ergonomic. I also have a Unix background in general, so it fits in my workflow fine.
I use it for anything. Writing, programming, configuring, etc.
I am learning emacs though: mit-scheme comes with edwin (like emacs), and since I'm learning Scheme, I decided ``why not learn emacs?''
Thus, I now use emacs bindings for line editing rather than IBM CUA bindings.
If you want to use an unusual editor, teco still exists, as tecoc, and I did get it to compile on OpenBSD: surprisingly, with a modified Mac OS X makefile, not with the GNU/Linux makefile. Sadly the guy maintaining it credited me with porting it to OpenBSD when I told him it compiled: surely I could do a real port if I put the time into it.


I also sometimes use ed for fun.


ssh is super easy on emacs with tramp. I don't have to leave my current emacs session to edit files over ssh. Just find-file "/ssh:<ssh host name from ~/.ssh/config>". Nothing wrong with sshing and running the machine's vi/vim though.


I've used the following editors in this order:

I was a VI fanboy for the longest but I got to admit, IntelliJ wipes the floor with all editors. There's not even a close 2nd to IntelliJ in my opinion.