editor thread?

vscode

File: 1482193207632.jpg (114KB, 1080x682px) Image search: [Google]

114KB, 1080x682px

>>60870241

>>60870220
Emacs

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

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

>>60870220
>operating system thread? inb4 gnu/linux shills appear

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

>>60870715
It's quite the mess.
Put this lua file into your ~/.textadept/themes folder https://pastebin.com/raw/dT0jjZzp
use this line in your init.lua

ui.set_theme('themename', {font = 'some font', fontsize = 00})

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

but thanks anyway

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

File: thanks cia niggers.png (56KB, 1072x710px) Image search: [Google]

56KB, 1072x710px

>>60870220

sublime because of pic related

vim for real nigga shit

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

>>60871004
kek

>>60870868
post your whole init?

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

>>60870220
Gedit.

>>60871115

ui.set_theme('darktheme')

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

>>60870701
but GNU is not a kernel

>>60871136

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.

File: eJwVzMENwyAMAMBdGABbODE42yCCCFUoCNxXld2r3gD3NZ95m8NcqmMdAGddqc_TLu0zlmxL7-XOcdRlU28QVWO6Wn7rAifsaGfc.jpg (10KB, 363x301px) Image search: [Google]

10KB, 363x301px

>Cast away your ideologies
>Use Atom

File: 1489581952796.png (189KB, 362x460px) Image search: [Google]

189KB, 362x460px

>>60871277
>atom

File: 1496585956035.jpg (59KB, 355x417px) Image search: [Google]

59KB, 355x417px

>>60871004

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

>>60870220
> Sandy

who /atom/ here

File: 1496438680152.jpg (254KB, 714x644px) Image search: [Google]

254KB, 714x644px

>>60872414

>>60872414
>electron
no

>>60870220
>not using emacs

vim / emacs is all you need

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

File: 1496854407569.png (592KB, 942x944px) Image search: [Google]

592KB, 942x944px

>>60872414

File: 1497174716987.jpg (36KB, 400x460px) Image search: [Google]

36KB, 400x460px

>>60872414

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

>>60873016
what is org mode?

Vim is love.

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

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

>>60873249
>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?

File: 164892946.jpg (9KB, 257x254px) Image search: [Google]

9KB, 257x254px

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

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

>>60873477
literally when is vim actually slow to use

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

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

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

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

>>60873451
https://github.com/Microsoft/vscode
show me exactly where the botnet is

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

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

>>60874160
>https://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!

>>60874274
it can have the best ux and the best extensions

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

>>60874314
>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?

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

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

UltraEdit masterrace.

File: emacs.png (18KB, 1596x1170px) Image search: [Google]

18KB, 1596x1170px

>>60870220
Go Emacs or go home.

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

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

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

File: smh-1.gif (81KB, 182x249px) Image search: [Google]

81KB, 182x249px

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

>>60876250
What's the sweet spot?

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

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

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

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

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

>>60876313
>I still prefer the point-and-click
You should really get rid of that idea, Anon. 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.

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

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

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

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

>>60876315
This is truth. C++ is disgusting.

>>60876373
>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?

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

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

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

>>60876522
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))

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

>>60876579
Yeah

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

>>60876522
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))

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

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

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

>>60876646
Shit, I guess I have no excuse, then.

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

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

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

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

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

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

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

>>60870220
geany shits all over ur fancy shit niggers