Editor thread?

Currently using textadept + textredux plugin which is very comfy and cross platform.

>inb4 vscode shills appear

Other urls found in this thread:

pastebin.com/raw/dT0jjZzp
github.com/Microsoft/vscode
en.wikipedia.org/wiki/Visual_Studio_Code
twitter.com/SFWRedditImages

vscode

...

Emacs

Tried it for a while. Seemed really nice.
But I missed some features coming from emacs. Especially trying to rebind certain keys didn't work well.

To me it seems like a notepad replacement that has some very nice additional features for programming, but somehow it just doesn't feel complete yet.

What did you try to rebind? Documentation is a bit lacking so if i can't figure something out i usually bother the dev directly and he always helped me out.

>operating system thread? inb4 gnu/linux shills appear

can you give me the code in your init.lua for setting that theme?

It's quite the mess.
Put this lua file into your ~/.textadept/themes folder pastebin.com/raw/dT0jjZzp
use this line in your init.lua
ui.set_theme('themename', {font = 'some font', fontsize = 00})

doesnt work for me, actually makes the background creamy white colored

but thanks anyway

Strange, i use this on three different machines (2 win, 1 linux) and it works fine on all of them.

sublime because of pic related

vim for real nigga shit

how long until the CIA starts hunting down everyone who uses the license illegally?

kek

post your whole init?

It's been a while so I don't remember exactly. I think I wanted Shift+Ctrl+{Left, Right} to move to the left or right tab. I couldn't figure out how to do that.

Gedit.

ui.set_theme('darktheme')

What's the point in using a text editor which can't run in a terminal and ssh? Vim is free of charge by the way.

but GNU is not a kernel

keys['csright'] = function() view:goto_buffer(1) end
keys['csleft'] = function() view:goto_buffer(-1) end

Personally i think ctrl+pgdown/up are better keys for that or just use the buffer switch list which is superior to everything imo.

Still using Sublime Text. I know Atom is more popular now but I don't feel like downloading and running a 300MB neutered version of Chrome to edit fucking text files.

>Cast away your ideologies
>Use Atom

>atom

...

can literally not reproduce your problem.
are you setting a theme in a different place as well?

> Sandy

who /atom/ here

...

>electron
no

>not using emacs

vim / emacs is all you need

this

I really wished vim had something like org-mode.
The existing version is pretty shite.

Still I'm going to go with vim but ONLY because it's light. I grew to hate how bloated Emacs is. Still a great editor.

...

...

There's a ton of projects trying to make it similar to org-mode, check out github for some.

what is org mode?

Vim is love.

A blast of a tool for GNU/Emacs.
There are plenty of Youtube presentations showing what it does and what it can be used for.

i admit, i fell for the M$ meme

but VSCode is the best thing M$ has done in a while

The point is that graphical editors have faster interfaces, offers features which makes them usable without needing to implement them yourself and you can avoid the decrease in productivity that follows vim.

I personally don't edit a lot of files over ssh, so I using vim for that is not a problem.
I guess I am intelligent enough to use the best tool for the job instead of being triggered by having several editors installed.

>graphical editors have faster interfaces
Kek.

>avoid the decrease in productivity that follows vim
My productivity increased exponentially since I started using vim. Perhaps you're doing something wrong?

how do people that use atom or vscode live with themselves?

>Microsoft tricked a bunch of autists to get their ""open source"" programme onto their computer
botnet

Vim does not update the buffer as fast as I would like, which is why I find it slower than editors which has a better graphical toolkit.

I was already productive with my editor before I started to use vim, so that might be the issue.
I tried to go full on vim for a while and I found it to be a distraction.
I don't do a lot of repetitive tasks to begin with, so that aspect doesn't really appeal to me and there is so many basic features you can't easily do with vim.
Often you stop your work to research how to do a thing, then you test a few plugins to see if any of those does it sort of the way you want etc.
So for me, I felt the best way to use vim was to use no plugins at all or use all of them.
With no plugins, you have a basic editor with no fancy features and that is fine for a lot of tasks.
It is slow and annoying to use, but you can use it.
The benefit is you have the same setup on every machine you ever meet and you don't need an elaborate backup system to manage it.

The other way you spend a lot of time finding the optimal solution to problems.

Currently, I use the no plugin approach.
If I need to do something more than a quick edit, I just use my main editor.

literally when is vim actually slow to use

Multiline edits is very slow for me compared to eg kate.
And I don't just mean the interface, the buffer update is slower.

but generally, the interface is just slower.
More keys to press, worse refresh rate and since it is easy to make mistakes in vim if you type too quickly, I have to slow down everything I do.

I evaluate software based solely on how much easier it makes my job, and not on ideology, politics and shitty memes

just like git gud with vim and it's LITERALLY the best editor evar and stuff lol

github.com/Microsoft/vscode
show me exactly where the botnet is

what exactly can vscode do that other editos can't?

>convenience at the cost of all else
>refuses to learn anything out of laziness
Good job, retard.

>en.wikipedia.org/wiki/Visual_Studio_Code
>Visual Studio Code collects usage data and sends it to Microsoft, although this telemetry reporting can be disabled.[19] The data is shared among Microsoft-controlled affiliates and subsidiaries and with law enforcement per the privacy statement.[20]
Wow, I sure wish Vim had this feature!

it can have the best ux and the best extensions

it also has the most development momentum core-wise and extension-wise.

>convenience at the cost of all else
no, functionality comes first and it has all the functionality I need

>refuses to learn anything out of laziness
what do you mean? what do I refuse to learn?

it can be disabled. you can even remove it from the source code and compile it yourself if you fear cosmic rays will hit your hard drive and reenable telemetry

This guy gets it. It could be just a way to identify people who browse WL on regular basis

UltraEdit masterrace.

Go Emacs or go home.

I'm curious how you are negatively affected by that which you call bloat in Emacs.

Notepad++ here. I just tinker with small personal projects, so I only really need it and a compiler. I'm willing to give something else a go, though.

Both emacs and vi are great for such uses. Both of them are "just editors"; they're just better than standard PC editors like NotePad++.

>Go Emacs or go home.
Go Emacs or go blind.

I use GNU/Emacs and could not conceive of using anything else at this point.
In the past I have used Sublime, Notepad++ and Vim.

>45 lines of code on a 1080p display
Most disgusting thing I saw today tbqh fampai. Why are you doing this to yourself?

What's the sweet spot?

The more the better as long as you can read the text at all. I'm considering starting to use glasses just so that I can decrease my font size a little bit further.
My Emacs is displaying 55 lines on my 1366x768 laptop, and 88 lines on my 1600x1200 desktop.

Sometimes it's easier with a large font, he might be using a laptop.

Far worse is the blatant disregard for any limit on line length. The 80 column rule persists because it's about right for optimal reading.

>Far worse is the blatant disregard for any limit on line length.
I almost agree with that, but the thing is that with most code, the thing you primarily need to read is at the leftmost side of the line anyway. If a long error message or auxiliary expression goes out of the way, that's arguably a good thing.

I tried both, and Emacs was my favourite of the two. But I still prefer the point-and-click, homosex, toddler editors more; Notepad++ and Sublime are pretty good in that respect. I tried things like Atom and VS Code, but they seemed confused about what they were trying to achieve. Maybe I should give Emacs another shot.

Also, you have to consider that the language he's using is C++. It's literally impossible to write C++ with less than 100-character lines.

>I still prefer the point-and-click
You should really get rid of that idea, user. Your comfort and productivity will skyrocket as soon as you don't have to move your hand back and forth between the keyboard and mouse.

Taking that further, one of the greatest advantages of Emacs is indeed that all of its commands are contained within the primary alphabetical part of the keyboard, so you don't even have to move your right arm to reach the arrow keys. Back when I started to use Emacs, that was among the things I appreciated the most.

>lab with classmates
>gui emacs guy
>needs to enter a few dozen blank byte values
>00 00 00 repeatedly counting in his head, manually inserting newlines to organize it
>be vim bro
>need to do something similar
>8i00 jkyy4p
>instantly done

user the tab you are using to write this uses dozens of megabytes of RAM. emacs "bloat" is nothing in comparison

>If a long error message or auxiliary expression goes out of the way, that's arguably a good thing.
Sure, but strings are basically the only exception.

Part of what makes Emacs so good is that you can easily bend it to your own style, which includes mouse-use. It has some neat things built in like double right-click kills (cuts) everything from the cursor to where you click, and you can define whatever actions you want in addition to that.

If you're really committed to mouse-based editing take a look at Acme, which was Plan9's editor. It was based on using mouse-chords for common tasks. The way most programmes today use the cursor seems primitive in comparison.

This is truth. C++ is disgusting.

>Sure, but strings are basically the only exception.
Nah, I have a few other good examples in some of my programs. For instance, in a program with a remote UI, I have a function that sends widget messages to the remote "terminal", which can take an arbitrary number of varargs for the message. When I'm reading through the code, 99% of the time all I want to know is that a line sends a message and what the name of the message is. I'd only care about the arguments if that's the specific line I'm looking for, so it's only good for the ordinary case if they go out of the way.

>start using emacs
>immediately angry because no tabs
>take time to understand buffers+windows
>finally understand why nobody bothered making a good tabbed browsing system for emacs

Tabbed editors are fucking gimped, I hope to never go back to one of those.

Why don't modern editors use buffers and windows? Are they purposefully producing bad software?

>Why don't modern editors use buffers and windows? Are they purposefully producing bad software?
I can only imagine. Another thing I just can't understand why they don't borrow from Emacs is its excellent and yet very simple undo system. The undo system is perhaps the closest to what I'd call a killer feature for Emacs, in that undo history is never lost, not even after undoing.

Yeah, and undo-tree is an excellent visualization tool for this.

And because emacs lets you make buffers that aren't associated with files, you can just M-x undo-tree-visualize on the side and browse your changes like a slideshow.

Can't believe newer editors don't have this

If all you've ever known is tabbed editors then that's all you will consider.

I feel like most of the computing interfaces around today had already been done better 30 years ago.

Please share your favorite elisp, fellow Anons. This is one of my favorite works:
(setplist 'no-such-buffer '(error-conditions (no-such-buffer error) error-message "No such buffer"))
(defun get-previous-buffer (numbufs blist)
(if (not blist) (signal 'no-such-buffer ()))
(if (not (buffer-file-name (car blist)))
(get-previous-buffer numbufs (cdr blist))
(if (> numbufs 0)
(get-previous-buffer (1- numbufs) (cdr blist))
(car blist))))

(defun switch-to-previous-buffer (numbufs)
"Switches to the previous file-associated buffer in the buffer
list."
(interactive "p")
(switch-to-buffer (get-previous-buffer numbufs (buffer-list))))

I have it bound to M-RET. It switches between the two most recent buffers. With prefix args it goes further back in the buffer history. I use it constantly.

I use the same functionality, but with evil mode's "evil-switch-to-windows-last-buffer"

I also copied something into my init.el a while back that splits helm's buffer view into files and non-file buffers, it's handy

(defclass my-helm-source-file-buffers-class (helm-source-buffers)
((candidates :initform
(lambda ()
(mapcar 'buffer-name
(cl-remove-if-not #'buffer-file-name (buffer-list)))))))
(defclass my-helm-source-nonfile-buffers-class (helm-source-buffers)
((candidates :initform
(lambda ()
(mapcar 'buffer-name
(cl-remove-if #'buffer-file-name (buffer-list)))))))
;; Use the decomposition for helm-mini
(setq my-helm-source-file-buffers-list
(helm-make-source "Files" 'my-helm-source-file-buffers-class)
my-helm-source-nonfile-buffers-list
(helm-make-source "Buffers" 'my-helm-source-nonfile-buffers-class))
(setq helm-mini-default-sources '(my-helm-source-file-buffers-list
my-helm-source-nonfile-buffers-list
helm-source-recentf
helm-source-buffer-not-found))

>evil
Are you actually using Evil, senpai? I've been considering it to and fro, is it worth it?

Yeah

I'm used to vim keys and like modal editing, so it's nice for me. Also, it requires almost zero configuration

I have this bound to C-RET, it opens a fresh line even if point is in the middle of the current line, very useful.
(defun open-line (arg)
"inserts arg new lines below and move point without affecting current line
If arg is negative, insert them above instead"
(interactive "p")
(cond ((> arg 0)
(end-of-line)
(newline arg t))
(t (beginning-of-line)
(let ((currpoint (point)))
(newline (- arg) t)
(goto-char currpoint))))
(indent-according-to-mode))

I really should try it out. I just imagine myself being immediately confused by having a mix of Emacs and vi at the same time, though. Would take some serious time to get back to productivity.

>it opens a fresh line even if point is in the middle of the current line
Isn't that what C-o already does?

With evil, C-z toggles between "vi mode" and "emacs mode" in any buffer at any time.

Shit, I guess I have no excuse, then.

C-o inserts a newline at point, without moving point. Mine moves without breaking the current line. Like what o does in Vi, I think.

Although it turns out C-o is also called open-line, so whoops. I had the function I posted prefixed with my username.

Oh, I get it. I guess that might be useful.

>C-RET
Can't be used in a text terminal, kouhai. I use Emacs on remote systems in screen sessions too often to not be sensitive about that.

I can't remember the last time I seriously used terminal Emacs, but I'll keep it in mind.
If I need to access remote files I normally use tramp.

>screen sessions
Not him, but why not use TRAMP?

Mostly because I have some context on the remote systems and I want to keep the sessions separate, and also detach and reattach the screen session here and there.

Also, I find it starts getting a bit confused with tramp when you're starting to use shell or GUD buffers on different systems.

>refresh rate
What are you even talking about? Vim updates instantly.

geany shits all over ur fancy shit niggers