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

lainchan archive - /λ/ - 11743



File: 1447048898244-0.png (138.05 KB, 300x294, GNU.png)

File: 1447048898244-1.png (89.59 KB, 300x300, Vim.png)

No.11743

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?

  No.11744

I use brackets.

  No.11746

I use Sublime Text

  No.11748

>>11729
>Are you serious?
He's not. Emacs is asynchronous.

One of the main reasons NeoVim exists is because Vim is synchronous and the existing project makes it too hard to add, apparently.

  No.11751

Vim is just a text editor.

Emacs is a way of life.

  No.11752

File: 1447058732564.png (335.33 KB, 200x160, sam.png)

the one and only

  No.11753

I always wondered is Atom a great editor compared to brackets? i.e; for WebDev?

  No.11761

Is the previous thread beyond the bump limit?

  No.11769

>>11761
It's at the reply limit.

  No.11770

Is there something like a "programmers guide to Emacs" ?
When I started using AwesomeWM I looked at the structure of the lua.rc file and the API and started to code stuff. I screwed thing every second day, but now stuff just works™.

Most Emacs tutorials I find start to talk to you about the premade keybindings (which are a pain in the ass, if you have a keyboard like mine) and not about how to adapt Emacs to your use (which is, imho the most important thing).

  No.11771

Vim, but I don't love it.
I like the modal use and the intuitive keyboard fatalities but it's too big of a program with the legacy code and all that, complains over vim are generally the same everywhere. This is bad conceptually because I like minimalism but also practically because my computer is soykaf and vim hangs from time to time.
Tried emacs+evil and it works better, seems like a better option if I actually got good with the lisp configs but it's also very big OOTB, though more elegantly big and the GUI works more fluent than the console version. A web search shows that more than one person already thought of making a stripped down version of emacs, has anyone here tried one of those?
Neovim was slow too, so the soykafness of my computer must be a serious issue. I hope to see (or make) a couple plugins for nvim because I'd need alternatives to the ones I currently use in vim.

Question for vim users: what would you think about a separate --MOVE-- mode for vim? Because edition and motion are both crammed into the normal mode and separating them could lead to more intuitive key sequences.

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

I find keyboards too unergonomic so maybe an AI that would see how I code and predict my moves, eventually taking over my projects and finishing them in 1 ms.

  No.11778

>>11748

being asynchronous and the threading model are 2 separate things though

  No.11780

>>11743
> Do you use a common editor or something more exotic?
It's funny but I use Notepad++ because it is fast enough and has all the features I need. Haven't settled for linux editor yet, but I doubt that it will be vim or emacs.

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

Spatial visualization. I want to visually see classes, functions or methods as figures (spheres/squares/etc) in virtual space, with pipes and other neat connections between them. So that you could switch between layers and view objects and their connection, and up above to files that are in project. Such visual tool will greatly speed up construction of the mental image of the whole code project in programmer's head and will allow to quickly go through abstractions or code structure. Everytime I study new codebase or re-visit my own project, it takes too much time because when starring at text methinks "Soykaf, what a spagetti" even with clean code.

  No.11797

>>11780
>Haven't settled for linux editor yet, but I doubt that it will be vim or emacs.
Gedit is probably what you want then.

  No.11808

>>11780
>but I doubt that it will be vim or emacs.
You're restricting yourself to an underpowered workflow because you don't want to learn how to use a tool?
so you're one of those "programmers" huh?

  No.11810

>>11797
Didn't like it.

>>11808
>You're restricting yourself to an underpowered workflow because you don't want to learn how to use a tool?
>so you're one of those "programmers" huh?
I've seen this coming. Do you use sledgehammer for driving small furniture nails? I don't. And no, I'm not a programmer, so there is no need for "Powered™ workflow".

  No.11812

I started with Sublime and now switching to vim.

  No.11814

Emacs is too much.
I tried Vim/Vi and it was weird that I needed to enter commands to allow me to do anything. I tried to move but I could not unless I entered a command that would put me into a mode that allowed me to move but not type. And to type I had to enter a command that would allow to me type but not move.
I tried Nano and thought "How do I move...the arrow keys?" And yup it was the arrow keys. I tried to input text and it just works. I don't understand the point of Vim. What do you gain from having to enter extra commands to enter certain modes before you can do....anything? Why not just NOT do that like with Nano. Vim sort of feels like a prank for me. I use Nano for basically everything except when I'm working on a big project on my local machine, then I use Arcadia, which I've never heard of anyone other than myself using.
http://www.arcadia-ide.org/


  No.11817

>>11814
>I needed to enter commands to allow me to do anything
There are keybindings for that, by default 'i' puts you insert mode for writing and ESC puts you in normal mode for moving and editing.
>What do you gain from having to enter extra commands to enter certain modes before you can do....anything?
Having faster ways to do certain things that you'll do a lot of times if you're programming, for example if you want to change what's in a block of code, you type ci} which means "change what's inside the curly braces". That deletes what's in the block, puts the cursor between the curlies and goes into insert mode.
If you're willing to give it a second try you should read some vim primer, there are plenty of blog/forum posts explaining the basic keys.


  No.11821

>>11817
This here. At first it does feel awkward, and you end up fighting the modal nature of vim. But as you accomodate to the vim workflow, you end up saving a lot of time with features like the dot command, or cw or d% and that without macros.
Also whe you get used to moving around with hjkl you'll feel awkward going aalll the way to the arrow keys too often

  No.11822

>>11814
I really want to love emacs, but ctrl+mod is just 2autistic4me.

  No.11824

Modal editing and vim-shortcut are great, but the downside comes where you have to switch to something more usual. Then you end up with a document full of unwanted o,O,i,I,v, :w or screwing it up by pressing ctrl+w to remove the last typed word.

Vim is also a pain to configure imho. If you don't program much it's fine but juggling between different syntax and rules (say TeX, html, Haskell, Python and PHP) can get messy, and I never understand how to install plugins properly.

Tried Emacs but for now I don't feel like wasting time in something with a steep learning curve where vim works well generally.

  No.11826

I first used vim but i got interested in LISP and people usually advise using emacs for lisp. After using emacs for a little while i just found it easier to use than Vim. Elisp is nice aswell

  No.11830

>>11824
>Modal editing and vim-shortcut are great, but the downside comes where you have to switch to something more usual.
Yeah, I avoid making those instinctive keystrokes by looking at the keyboard instead of the screen when I'm writing in some other editor. Also, you can look for a plugin or something to get your web browser to use vim as external editor for things like posting here, pressing ctrl+w when you're writing a long post can be like kicking dead whales down the beach.

>Vim is also a pain to configure imho.

>Tried Emacs but for now I don't feel like wasting time in something with a steep learning curve where vim works well generally.
I agree about vim's configuration. You could try emacs (it has a UI for configuring (almost?) everything (even in terminal mode (but that one can be less comfortable (but you can configure (almost?) everything using the GUI then go back to command line)))) in evil mode, which configures emacs to use vim keybindings everywhere.

>and I never understand how to install plugins properly

Have you tried using a plugin manager? I use one called voundle, you type the names of the plugins you want in .vimrc and :PluginInstall :PluginRemove and :PluginUpdate do the work for you. Emacs does this better for a couple reasons, for instance you can install plugins without looking them up online or writing manually to the config files, in emacs it's like using a package manager. And it includes alternatives to vim plugins for using in evil mode.

  No.11832

I use emacs + terminal. But Im an emacs pleb, I only really know the basic shortcuts nor do I know elisp so my emacs is not riced out. I just use it because I used to use vi (and before that geany) and wanted to try something new.

I dont usually like programming with IDEs for various reasons but I will say that it is sometimes a pain when Im learning a new language, to get my terminal compatible with the compiler. For some languages its as straight forward as setting the path in your .bashrc but I had a lot of trouble getting Go to work for some reason.

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


I am looking forward to atom getting its kinks worked out, its really laggy and I have an i5 so idk. Ill admit sublime text is a really nice editor I really want atom to be as good as sublime.

  No.11834

I've wanted to like emacs. I've made several attempts at learning and using it, but no matter if the attempt was in 1996, 2003, 2010, 2015, my emacs install/config eventually becomes a mess of plugins and config changes that result in a stream of lisp errors on startup that I cannot debug. Other than that, I often find emacs becoming unresponsive at weird times, or key input is being grabbed by some broken function that is never released, and I'm forced to kill emacs and start over. The UI is soykaf an unresponsive. Emacs simply does not work for me, it gets in my way more often than it helps. The only time emacs 'just works' is when it's something like mg, in which case it's just like any other plain editor but with soykaf default keybindings. I give up on it.

I don't have a favourite editor, but I use vi/vim/neovim and trying atom, which despite hurrdurr javascript, hurrdurr editor-in-a-browser, has worked better for me than emacs ever has.

  No.11850

I use emacs and Vim interchangeably from time to time. I'd use emacs+evil alone, but it's kind of awkward using emacs keystrokes for half of the tasks, and vim keystrokes formthe other half, especially since I have to remap Caps_Lock to either Ctrl or Esc.
I love emacs for it's community and several facilities like having everything in one frame. But Vim keybindings are far more efficient imo and it feels I'm doing it the unix way (even if this last thing is a superfluous one)

  No.11855

>vim
>no concurrency
>no daemon mode

It's ogre. Vim lost.

  No.11863

>>11855
>what is neovim

  No.11865

>>11863
>it's so bad it needs a complete rewrite to be modern
It's ogre. Vim lost.

  No.11871

>>11865

emacs needs a complete rewrite to be modern too

  No.11873

>>11871
>to be modern too
What doe s this even mean?

  No.11876

>>11873
Emacs is too useful to be modern software.

As for NeoVim, it seems interesting enough. It's already scriptable in Common Lisp now, so that's something.

  No.11877

>>11780
If you don't like Gedit, you could try Textadept. I didn't really like it, but it's the closest editor to Notepad++ that I could find on Gnu/Linux.
Still ended up using vim tho.

  No.11880

>>11743
obligatory vimmasterrace comment

  No.11896

>>11865
>Vim
>bad
Now you're making soykaf up.
and Vim is itself a rewrite of Vi. I don't see any problem in refactoring once again, it's usualky a good thing to do that.
Vi is evolving, sublime, atom, and those shitty editors son't evolve, they're proprietary, they take upon ideas introduced by venerable editors like Vi and Emacs, and they don't really introduce new concepts, they just make a sort of gedit/notepad with syntax highlighting and a feature from the classics, so the user doesn't need to learn too much and can continue on clicking the way windows educated them to do.
They're simply not superior, and they won't endure like the paradigm that Vi in itself represemts, nor do they account for the power thatnserious programmers look after in their editors. That's the reason people end up trying Vi or Emacs after using atom forma while, and when they learn it and discover how swift and proficient they become, they don't go back.
Unless they're casual users and realky don't need all that power

  No.11902

>>11896

In what way is atom proprietary?

  No.11905

>>11753
I use Atom, it's fine.

  No.11907

>>11880
Obligatory emacs master race reply

  No.11911

>>11902
In a way that its not Vim. That means it is proprietary.

  No.11925

>>11688
Apparently in 25.1 the package downloads will be async.

  No.11927

I use Emacs+Evil because every vi implementation I've tried was awful (especially Vim).

  No.11929

I'm going from Vim to Emacs(Spacemacs) right now. Vim was shitting all over the place with a few plugins, and it's cumbersome to move output to/from a REPL.

Still fumbling around but it's obvious there's tons more power to make things how I want with Emacs.

  No.11944

>>11927
What is awful in the Vim way of implementing Vi? I'm pretty curious.

  No.11965

>>11748
Emacs is asynchronous, but it isn't threaded.
There's a project to add threaded processing to Emacs, but I'm not sure how far along it is.

  No.11966

>>11944
Vimscript might just be the ugliest thing I've ever seen. Also, it tells me to donate to Uganda.

  No.11977

>>11966

Is ugandaware RMS approved?

  No.11978

>>11977
It's free software, yes.
As far as RMS is concerned, the Emacs/Vim debate is just a bit of playfulness.
https://www.youtube.com/watch?v=S76pHIYx3ik

Of course he prefers Emacs, because he wrote it.

  No.12094

File: 1447856849839.png (97.81 KB, 184x200, title2.png)

Went from vim to spacemacs for programming, looks great so far and there's a ton of stuff I haven't tried yet. Leaving the console feels good in this case.

I have two problems with it. I keep forgetting some of the SPC-a-b-c combos and couldn't find a cheatsheet like this >>5520 for spacemacs.
The other thing is that I can't find out why some settings aren't loaded on startup, for example I went to :customize, changed the powerline separator to nil and clicked "apply and save" which added '(powerline-default-separator nil) to custom-set-variables in .spacemacs but when I close and reopen the program it has the default separator.

>>11780
>Spatial visualization.
Same. I think it would be a great emacs layer or feature for any IDE.
Scanning the code and rendering a graph doesn't sound hard to do, not that harder than syntax highlighting.

  No.12099

>>11780
I'm pretty sure most popular IDEs have some plugins for UML reverse-engineering and generating call-graphs.

  No.12110

>>12094

When you hit space, doesn't it bring up helm screen at the bottom with all the available keys listed? It does for me..

  No.12113

>>12094 here
Solved the customization problem by manually adding commands to dotspacemacs/user-config() in .spacemacs, the hard part was to find the commands that did what I wanted.

>>12110
It does, I think I was just tryin to rush through the learning process.

  No.12121

>>12113
If you're trying to configure something in Emacs just search the functions and variables (C-h v/f) for keywords related to what you're looking for. Spacemacs has Helm, which should fuzzy match the whole list. Emacs will tell you what the variable/function does, how it's defined, and how it can be modified.
When you've found what you're looking for you can just put (setq <variable> <value>) or a function call in your init file.

  No.12127

I use atom as my daily driver, I don't recommenced it yet but in time ones the technology is more developed and "better" then I feel like it can be considered one of the better text editors.

It's already leagues ahead of sublime in everything but speed

  No.12267

>>11743
Emacs + Evil for most of my programming needs (except Java), vim/nvim on the command line, via ssh etc.

Atom if I just want to quickly open/edit a file in a graphical environment.

inb4 "Atom so slow"

  No.12297

>>12267
Why would you use Atom when you seem to be proefficient with both vim and emacs?

  No.12305

>>12297
I only use Atom as my "graphical" kind of toy editor, this is by no means necessary, vim does the job as well, but this is fast (especially since I like to keep notes in .md files and atom has the preview out of the box and is quick to set up).Bit for fun and playing around, so me using atom is not that serious.
It was also turned out as a nice way to view and edit json files. For some reason, emacs chokes on json files with >1million words (opens and reads them fine, but pretty print buffer kills it =( havent figured out if this is just an emacs thing, I'd rather assume that it's because of the json package)


I use vim when I'm already in the command line and want to create a file or edit a file from there `vim file`.

I use emacs when I actually program and hang out in my editor for a longer periods of time, you know what I mean?

  No.12309

>>11751

Jokes aside, I think both can be very "way of life"-y, just in different ways. Emacs folk tend to integrate everything into Emacs (mail, www, irc, etc...) whereas vim folk, at least the biggest fans, inject vim keybindings into everything: PDF readers, window managers, web browsers...

  No.12310

I enjoy acme, although it's certainly an acquired taste.

  No.13377

File: 1452464945959.png (29.32 KB, 200x197, 1444242755603.gif)

Subject: Emacs packages sub-thread

The stuff you can do in emacs is a world on its own, what do you (want to?) use it for? How was the journey until you got it working?
Doing everything in (spac)emacs seemed like fun but recently I failed to get wanderlust (configuring it is black magic, they should steal some ideas from thunderbird) and pdf-tools going, couldn't find a bittorrent client and :term is gimmicky sometimes, mostly for ncurses stuff.
What worked is ranger for a file manager, newsticker for rss and org-mode.
Does somebody know why some packages are uninstalled when I restart emacs, after installing them with install-package?

  No.13378

>>13377
I install all of my packages manually. I just dump them in a subdirectory of my ~/.emacs.d/ directory and add the code to my ~/.emacs configuration.

I use Emacs in some way for everything but browsing the web. I control my Lisp implementation with SLIME, I control gforth with gforth.el, which is missing from the base installation of Emacs, I use eshell as my shell, I use dired as my file manager, I use ERC as my IRC client, and EMMS is my music player.

I should really configure Emacs to be my mail reader too, but I haven't done that yet.

Unfortunately, Emacs always hangs when trying to read PDFs, so I use dired's ! command to dispatch mupdf on them instead.

EWW doesn't work well with Lainchan, so I'm stuck using Firefox for that.

I haven't really had many problems.

  No.13380

>>13378
>I use eshell as my shell
please don't do this
didn't you read the eshell manual?
basically eshell was written to make IO work with emacs buffers, which makes it terribly bad for using pipes.
Use M-x shell instead

  No.13381

>>13380
I almost never use the shell. If I do, I'm launching a one-off program like youtube-dl or sysctl.

I get the most use out of M-! and dired's ! command.

>didn't you read the eshell manual?

I vaguely remember it.

  No.13538

>>13378
>Emacs always hangs when trying to read PDFs
With pdf-tools? Can you tell me how you got that to work, even if it hangs?

  No.13539

>>13538
It uses DocView.

  No.13552

>>13538
I feel like I should also point out that it doesn't hang on smaller pdfs.

Most of the pdfs I try to read are hundreds or thousands of pages long.

  No.13562

File: 1453154819799.png (101.51 KB, 200x150, sun_keyboard_left.jpg)

The Unix Sun keyboard layout explain some of the quirkyness of Emacs & Vim. The ♦ symbol is the famous meta key.

  No.13566

>>13562
oh interesting, the control key and caps lock key were switched. They should have kept that style.

  No.13571

>>13562
>The ♦ symbol is the famous meta key.
uh, meta has always meant the alt key. did you mean the super (now windows logo) key?

  No.13576

>>13562
What? No?
Emacs was based on the old Lisp Machine keyboards(there's like, a gorillion), obivously

Vim was based on the ADM-3A, if you look at the keyboard it even hast the HJKL left down up right arrows on them.

  No.13581

>>11752
What the fuarrrk are 'snarf' and 'plumb' ?

  No.13593

Stupid question: does Emacs CUA mode hamper other keybinds at all? Friend is asking and I'm not sure because never used them.

  No.13595

just nvi. i hate having a turing complete language interpreter in my editor, and syntax highlighting is juvenile. vi bindings are the best in my opinion because they are mostly really simple and memorable.
>>13581
in plan 9, the original operating system that sam came from, "snarf" means copy and "plumb" means send to the plumber, which took the plumbed data and sent it to the right program, so if you plumbed a url a web browser launched or if you plumbed an image, the image viewer appeared.

  No.13598

>>13595
>plumb

That sounds amazing honestly, any ideas how one can emulate that with a copy of Linux? Searches only gives me pipe tutorials.
If this has been a standard feature in Linux, please smack my head in for me being a total pleb

  No.13604

I use Sublime Text 2, It is just easy, and its package library is pretty huge.

  No.13609

>>13598
xdg-open?

  No.13610

>>13609
>xdg-open
I never knew, thanks chummer!

  No.13663

>>13609
comparing xdg-open and plumber is a joke

>>13598
plan9port

  No.14304

File: 1456198526198.png (903.95 KB, 200x145, Screenshot from 2016-02-22 22-31-02.png)

Emacs is simple, configurable, and beautiful.

  No.14306

I use Sublime Text 3 but I heavily rely on the vim commands they have, and multiple-selection is a god send. I respect vim users, but I think people who complain about Sublime simply because it isn't vim are mislead. I'm very productive with it.
I do use vim on my linux partition. I've never used emacs but I guess I ought to.

  No.14309

From afar Emacs looks so much more coherent and efficient than any other desktop environment. I'm tempted to try it with evil mode but so far vim is pretty confy with the tabbed NerdTree and a few macros:

"nmap <F2> :NERDTreeTabsToggle<CR>
nmap <F2> :call ToggleVExplorer()<CR>

  No.14310

I use Vim. It's just too comfy.

  No.14316

<3 emacs.
Ive got its setup all nice with completions and spellcheck. Orgmod is godly.

Default bindings dont bother me, they are fairly easy to remeber and caps=ctrl so no
emacs pinky!

But also emacs makes more sense for me as i use
lisps somtimes and its just more conveinient than vim for that imo.

  No.14318

i use vim.

once you grok the motions and how a modal editor works you'll never (want to) look back.

i have also been playing with vis
https://github.com/martanne/vis
an even more minimal, vi like editor.

  No.14321

sublime

  No.14325

>>14304
What terminal? I need to know because of reasons.

  No.14327

>>14325
cool-retro-term

https://github.com/Swordfish90/cool-retro-term

I used it for a while. Some of the effects are cpu-intensive, but it looks awesome and is very configurable.

  No.14328

>>11780
Bluej (lightweight java ide) kind of has this. When you open a project, you are shown a window with all files drawn as a rectangle. Solid arrows from one rectangle to another show inheritance, dashed arrows show use. You can drag the boxes around and visually lay things out to make sense.

Double-clicking a box opens the editor. It's pretty straightforward but has 2 features I like:
1. colored rectangles around different kinds of blocks (class, method, conditional, loop), with lighter shades indicating heigrarchy
2. a miniature view of the entire file as a skinny column on the right side of the editor, including colored rectangles. Once you get accustomed to a file, this allows you to quickly get an idea of where in the file you are.

http://bluej.org/

  No.14331

>>14328
In my intro to programming class the lecturer made us use BlueJ so we would appreciate what a real IDE did for us. It was awful. Java is one of the few languages where a proper IDE, not just a fancy text editor, is essential for anything nontrivial.

  No.14333

I use generic notepad++

  No.14339

VI VI VI !!!

  No.14345

>>14339
the number of the beast?

  No.14346

>>14345
The Editor of the Beast

  No.15862

I've historically been an emacs guy, but some videos of people using Sublime/Atom I've been seeing have made me jealous.
(e.g. multiple variable names, or multiple attribute values/css classes).

  No.15864

>>15862
>multiple variable names, or multiple attribute values/css classes

Could you explain this?

  No.15876

File: 1461461011509.png (6.54 MB, 200x125, sublime2-2016-04-23_21.19.09.webm)

>>15864
something like this, being able to make multiple edits in the file simultaneously

while I'm sure this may be possible in emacs, I can't imagine it being as smooth

  No.15885

>>15876
You didn't even multiple-cursors.el, but you can't imagine it being any better? Out of the various multiple cursors implementations I've tried, the emacs one is the best. It can do everything shown in that webm.

  No.15907

>>15876
What's the point when regex exists?

  No.15912

What do you guys use for refactoring and project management in Emacs?

  No.15913

>>13598
If you use plan9port, you can write a launcher that launches both the plumber and acme, and shuts down the plumber when you exit acme.

The script I wrote even gave me the ability to have a .plumb file in my home directory with all my rules, unfortunately I lost it.

  No.15916

>>15876
It's called multiple-cursors, and it functions identically (and works perfectly with things like paredit and smartparens-strict for structural editing)
But hey, regex-replace is a thing too.

  No.15917

>>15912
find-file and dired (???)

  No.16171

I've used vim for years but lately I am using Geany for development

  No.16178

>>15876
you need that functionality because you're writing in a language that doesn't allow adequate abstraction or you just have shitty habits.

of course emacs and vim can do that but my point is git gud.

  No.16190

>>11743
I use emacs, and it's currently the best text editor out there, but I won't pretend it doesn't suck. I can't wait for another, better, editor to come along and eat it's lunch.

>written in elisp, a variant of lisp made for and used exclusively in emacs and nowhere else, both limiting the use of elisp programs and preventing emacs from fully leveraging the active development communities in other languages

This is enough of a problem that I think it's probably one of the root causes for many other problems in emacs.
>world's shittiest user-interface
Great example of the above. Elisp has no concept of a UI, only text-buffers. The hack-y solution for this is to just shove everything into text-buffers and the rest into X11. As a result, every editing session gets littered with dozens of buffers for things like auto-completion, M-x'ing, file-finding, etc. Every time you want to swap buffers to a file that's actually being edited you have to sift through all that cruft sitting around in your memory to get to anything.
>refusal to integrate or take advantage of the mouse
>no concept of layered commands which act or modify one another and text objects (e.g., vi's word/paragraph/etc. selections that can be acted on my arbitrary commands), but at least there's paredit & co.
>shitty keybindings which, because they're the editor's default, act as inspiration for every other elisp package's keybindings
They're stuck in a limbo between mnemonic commands (C-f, C-b, and other basic commands) and, well, everything else. Killing a region is C-w, for some reason. M-d kills to the end of the word. M-k kills to the end of the sentence. Fine and dandy. M-backspace kills a word backwards. Fine and dandy. How do you kill a sentence backwards? C-x, then backspace. Where did that come from? Why are some sentence operations in the C-x extended prefix map and others outside of it? Keybindings aren't consistent at all. Sure, you can change them, but because they're also the used as the default bindings for almost every elisp package out there, you have to change them for every package you download. It's more convenient to just memorize the quirks and get to work.

Anyway, great editor, but not without its share of problems and annoyances. I've used and liked Emacs, vim, and Acme. I really wish there was an editor out there that married the best of the three of them, but I doubt it's going to happen. Most programmers are comfortable enough using a large (usually language-specific and commercial) IDE to the point where text editors probably aren't ever going to be able to compete for developer attention, meaning what we have now is what we're going to have for the foreseeable future, barring clones of the above editors and tweaks.

  No.16191

>>16190
>>world's shittiest user-interface
Whole-heartedly disagree.

>Great example of the above. Elisp has no concept of a UI, only text-buffers.

This is a strength of Emacs. Basic concept (buffers) that gets used for everything means that everything is more predictably designed and hackable. I can traverse any user interface using commands I already know because it's just text. At any given moment I can just M-x fundamental-mode and start editing the UI I've been using. I commonly do this with shell outputs in eshell/other shell outputs. I'm very glad Emacs is not like a normal editor in this way.

>Every time you want to swap buffers to a file that's actually being edited you have to sift through all that cruft sitting around in your memory to get to anything.

ido fixed this for me, it comes built in you just have to add it to your init.el (ido-mode 1). I can't remember the last time I went to *Buffer List* for purposes other than just clearing our all the buffers I've built up over time. I use desktop saving so buffers get saved in between sessions.

>>refusal to integrate or take advantage of the mouse

Another strength, the mouse is slow and I like using Emacs without X sometimes.

>shitty keybindings

I agree that the default keybinds are shitty but if you know how to use vi you should be using evil (and evil-surround) in it anyway. It integrates surprisingly well with the keybinds already present in Emacs and I find both vanilla Emacs and vim to be intolerable for lacking keybinds on present in Emacs with Evil.

>because they're also the used as the default bindings for almost every elisp package out there, you have to change them for every package you download

I haven't run into this too much.

It seems like our experiences are different but it also seems like we value different things. I'd like an Emacs that uses something other than Elisp (preferably Scheme or a variant) but I rely on so many packages built for Emacs that moving to another editor and sacrificing those packages would be too irritating to be worth it. I wouldn't be surprised if I use Emacs for the rest of my life.

  No.16192

>>16191
I think you got the impression that I dislike emacs, even though I tried to clarify that twice in the post. I'll probably use it for the rest of my life too, but that doesn't mean I can't acknowledge its mistakes.

As for ido, that doesn't change the fact that those buffers are still sitting around in your memory for no reason.

Regardless of whether we like or dislike using the mouse, it's a tool present and should be taken advantage of. Or at least treated in a consistent manner. Whether or not we use the mouse regularly, treating it inconsistently is worse than ignoring it completely. Setting a mark in a buffer using the keyboard, and then moving the cursor to an arbitrary position with the mouse doesn't select the region (the expected behavior, and what occurs when you move the pointer with the keyboard): it resets it. I wouldn't mind it if they ignored the mouse completely, or at least let it act as a stand-in for pointer controls like normal keyboard movements do, but treating it inconsistently is just bad.

>just use evil

Isn't a solution to broken defaults that act as a standard for all other packages. There's not really any solution here though.

I don't mind buffers for text, but when emacs uses text to represent things that aren't plaintext, that's not good. This isn't a problem with emacs so much as it is with elisp. If elisp properly supported building UI's or had and used bindings to toolkits (like Guile, Common Lisp, Racket, Python, C, etc. do) there's literally no reason you couldn't hack around with them in emacs just as easily. For proof, see any variety of Common Lisp environments, but especially Climacs and (Mc)CLIM. You don't give up predictable and hackable design or modifiable UI by doing the right thing or using the right tools.

  No.16194

File: 1462583196340.png (91.6 KB, 200x113, 2016-05-06-175647_960x540_scrot.png)

>>16192
>I think you got the impression that I dislike emacs, even though I tried to clarify that twice in the post.
I didn't mean to imply that, I just wanted to give you advice because it seems like you don't like some things that seemed fixable in one way or another, and I like the discussion. Sorry, I didn't mean to come off that one.

>As for ido, that doesn't change the fact that those buffers are still sitting around in your memory for no reason.

Personally I prefer it this way. I like being able to type C-x b "foo" to get the most recently used (and probably relevant) file that matches "foo" again. IMO It's not a waste if it's useful, and I like being able to zip around files I commonly edit like this. For example, at the moment I have an rc file buffer, a dired buffer for a directory of a game I've already beat, one for an anime I've finished etc. I understand this might bother people but it's just how I use Emacs (and how I feel like I'm supposed to, given how generally opening another buffer is the default behavior of keybinds instead of changing the current buffer).

I see why you're bothered by the inconsistent design, and I agree that it could be better in general-- the way code is written is also inconsistent due to Emacs' long development history. I suppose this is a matter of taste, but to me it isn't a major inconvenience so I can live with it.

>Isn't a solution to broken defaults that act as a standard for all other packages. There's not really any solution here though.

For modes that have their own set of keybinds, normally I have to learn all of them anyway, so I guess I just don't approach them with the expectation of being able to match them to normal Emacs binds (which I don't use too many of in the first place)? To be honest I've never heard this complain before so I don't know if I'm even addressing it correctly (sorry).

I stand by my text focused UI preference, but I'll check out Climacs. I'm wary of the concept of a "right tool" when a "less right tool" is equally functional and allows for easier traversal, and I like that there isn't anything too "special" (although Emacs does have images and you can build UIs like in pic). It would be neat if such UI widgets were buildable from the ground up with Lisp, and the default ones defined in this way. Is that the case with Climacs/McCLIM?

  No.16205

>>16194
> I like being able to type C-x b "foo" to get the most recently used

I'm not the person you were talking with before, but I don't see what recentf has to do with useless buffers still hanging around. As an example, you can have dired clean up after itself if you want, but there are some packages that leave around buffers you would never want to use again. I use ivy/helm (over ido), so it doesn't affect me either, but it is a valid point. Some packages are worse offenders than others.

>>16192
>(Mc)CLIM

Isn't clim basically dead? Climacs is definitely pretty dead, and as much as I wish emacs had been (re)written in common lisp, it looks like that's never going to get anywhere. As for using something other than elisp, at best, guile emacs will eventually be usable/endorsed.

  No.16206

Don't hate too much, but, Atom. I have a Hi-DPI display, most of what I do isn't functional/esoteric/"alternative", and the plugin support is fantastic. I use vim mode support so I still get my super fast text processing capabilities, but I also get rich text support, easier theming, better mouse support, and everything else that comes with a GUI.

Oh, I also have 16 GB of RAM, so I don't notice any lag.

Just to be clear, I don't like it, but it's more suited to me than the rest.

  No.16209

I use emacs.
I started out with sublime text and the plugins seemed kinda meh
Then I moved to vim, but I found modal editing got in the way for me
And now i have landed with emacs. I like it a lot, I don't mind the default key bindings, and elisp has lead to some fantastic plugins.
Also its best for general lisp things I think.

>>16206
You are way to worried about people biting your head off for using atom :P

  No.16210

File: 1462657301306.png (322.73 KB, 133x200, gedit.png)

Gedit+Perl.

Small and simple, with {syntax, matching bracket, 80th col, current line}-highlighting, line numbers, and search/replace.

I've seen a plugin option in one of the menus so presumably it supports more, but I've never found cause to want more.

  No.16213

>>16210
Oh, and it monitors files for modifications and offers to reload them very quickly without fuss. That's a big deal.

  No.16217

File: 1462668017301.png (33.93 KB, 200x80, hhkb.jpg)


  No.16219

>>16205
I didn't mention recentf in my post. I was referring to how ido lists buffers by how recently they were selected.

  No.16223

>>16213
What editor doesn't do this?

  No.16224

>>16219
I know, but it doesn't matter whether buffers you were actually using are still open. That's not the cruft he was talking about. None of the examples he mentioned were buffers you would use more than once.

  No.16230

Every time I use emacs for a while I end up rage quitting, after having updated some random package causes a clusterfuck of errors, I don't like lisp and don't want debug it. I've never come across a more self absorbed software package in my life.

  No.16231

>>16230
I promise you that you can install a shitty package on any text editor with a package or add-on system. I suggest avoiding doing this.

  No.16232

File: 1462701918513.png (44.45 KB, 200x82, Stallman Email 2004 HHKB.png)

>>13571
https://en.wikipedia.org/wiki/Meta_key
I have two different versions of the Sun-layout keyboards made by two different vendors. I can confirm it was replaced by / works as a Windows key.

The terms "Meta", "Super", "Windows" and "Hyper" aren't really interchangeable between vendors or even sometimes OSes (BSD tends to prefer Super). You have to look at and go by the keycode actually sent by the keyboard (showkey).

>>13576
It's designed to work with the Sun layout. See pic.

  No.16233

>>16223
I just opened test.c in vim, executed "perl -i -pe 's/int/short/g' test.c", and vim said nothing.
So I focus vim, and it still says nothing.
So I move the cursor around, and it still says nothing.
So I edit the file, and it still says nothing.
So I save my changes and the only option it gives me is 1) clobber the changed file or 2) don't save.
Vim handles this in a completely unacceptable manner.

I just opened test.c in emacs, executed "perl -i -pe 's/int/short/g' test.c", and emacs said nothing.
So I focus emacs, and it still says nothing.
So I move the cursor around and a little red 'M' appears that is 1) easy to miss, 2) doesn't give me any options at all.
So I try to edit the file, and it finally gives me the options I need, blocking me from editing it until I decide.
Emacs makes it a pain in the ass.

I just opened test.c in gedit, executed "perl -i -pe 's/int/short/g' test.c", and gedit said nothing.
So I focus gedit and it brings up a large yellow bar with options to reload the file or not, and it blocks me from editing it until I decide.
Gedit makes me use the mouse.

It isn't perfect, but it's a damn sight better than (unconfigured) vim or emacs.

  No.16234

>>16223
>>16233
Nano takes the vim route and tells you fuck-all until you try to save, and which point one receives:

"File was modified since you opened it, continue saving?" Which is completely unacceptable.

Pico also takes the "fuck you" route of vim and nano.

Which editors do it?
Only gedit that I can see. Maybe the others can be configured to not fuck over the user by default (vim,pico,nano), or not be a pain in the ass (emacs).

  No.16235

File: 1462705756363.png (15.27 KB, 200x125, gedit2.png)

>>11810
>Didn't like it.
The latest version of gedit has some retarded UI update that makes it awful to use.

Did the version you used look like this, or have some "easy to use" bullshit shiny and slow interface?

  No.16240

>>16233
>>16234
First of all, this is a terrible example because you can just use the editor's search and replace. At least in this case, there is no complicated regex used where one might benefit from using perl. That's not to say that running a shell command on the current buffer could never be useful. I'll also initially ignore the fact that you can filter the current buffer through a shell command directly from inside vim and emacs.

I open up test.c in gvim with no configuration. Run "perl -i -pe 's/int/short/g' test.js". Immediately it tells me the file has change with a popup to reload or not reload the file. If I don't like gui popups, I can just as easily make the popup appear in the bottom and allow the options to be selected with the keyboard. I don't expect an editor that runs in the terminal to be just as nice as a GUI editor without configuration and am able to use a search engine to instantly find out that I can also have this happen in terminal vim with a single line to, for example, cause :checktime to be run more often. I'm also able to read the message in the Ok/Load prompt and look up the help for 'autoread' afterwards to realize that I can set it to automatically reload buffers. Ignoring the fact that vim has regex search and replace, I decide that in the future I'll use '%!' to automatically filter the current buffer text through a command and replace it directly.

I open up test.c in emacs. Execute "perl -i -pe 's/int/short/g' test.js". Nothing happens because I don't have auto-revert mode on, and I can't be bothered to configure emacs. I decide I want to throw away the change I just made and try to save the file, and it clearly notifies me in the echo area that the file has changed and prompts me as to whether I really want to save it. I change my mind, don't save it, and revert the buffer to see my change. I decide that it's not too much effort to add '(global-auto-revert-mode 1)' to my init file and do that. Next time I run the command, the buffer automatically updates. Maybe I don't want that for some reason, and would prefer automatic polling and alerts, so I implement them myself since I'm using a programmable editor. Ignoring the fact that emacs has regex search and replace, I decide that in the future I'll just filter the buffer text through a command directly. With evil, I can even do it in the exact same way as with vim.

Let's also look at some editors that are less popular than pico and nano for a second. Sublime has an option to choose whether you want to automatically reload or to prompt (don't remember which is the default). Atom requires a package for this, but it's still easily possible.

  No.16241

The dream would be to have a text editor engine that is abstract enough and that could be used as a basis for arbitrary editors. With plugins that interact only with this engine, you could have a plethora of different tastes for editors that share the same structure and plugins, having nothing to sacrify.

  No.16242

>>16240
> test.js

I think you mean test.c?

  No.16243

>>16241
Emacs does provide emulations of several editors including Wordstar, TECO, Vi, et al.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Emulation.html

I think the work going into Guile Emacs is very interesting. Guile is actually a VM for several languages, including Emacs Lisp, Scheme, ECMAScript, and it's getting support for Lua. This would mean a Guile Emacs can have extensions written in any of these languages.

  No.16246

>>16205
Yes, Climacs and McClim are basically dead. They're just good examples of how you can still get a hackable Lisp UI beyond arbitrarily forcing everything into text-buffers because your language doesn't support anything more than that.

  No.16247

>>16243
I'm not talking about emulation, but more about how WebKit can be used to create different browsers, but in a lighter way. Abstract away the GUI, besides the plugins, etc... So you could have from a full-normie editor to full blown configurability, while still sharing most of the structure.

  No.16248

>>16247
I think a really good idea for an editor is "editor-as-specification", similar to how Common Lisp and Scheme are specifications which can be implemented by different groups. You specify the behavior and so forth of the editor, and then others can create their own editors in whatever language they want that follows that spec. That's not very similar to what webkit does though, which provides the core of a browser and lets others create plugins and gui's, but you could do something similar with an editor-as-specification-manual

  No.16249

>>16248
Yes, that's more or less what I thought. Possibility of interchanging parts that are coherent and obey the same interface. That would be really nice.

Yi has a lightweight core and multiple possible GUIs, but I don't know much more than it. It does not seem to be one of their goals.

  No.16264

I usually use TECO as my editor. There's nothing more fun than memorizing hundreds of single letter commands.

  No.16268

>>16240
>First of all, this is a terrible example
You've misunderstood, it isn't an example of a good reason to use perl but rather an example to bring forth each editors behaviour when files are changed.

They all have the same behaviour regardless of what the change actually was, so the change doesn't matter at all.

>I don't expect an editor that runs in the terminal to be just as nice as a GUI editor

In this matter there is absolutely no reason a GUI editor should do this by default and a CLI one should not. There's no difference here.

>:checktime

>autoread
I explicitly said in my post other editors can probably be configured to not fuck the user over by default.

It oughtn't be necessary. If emacs deleted random files from my system, the fact that I could disable this behaviour doesn't excuse it being the default.

Having good defaults is far more important for CLI programs than for GUI programs, because CLI programs as useful as text editors are often run over SSH in environments where the user ought not, or can not, write a config file.

>Ignoring the fact that vim has regex search and replace

>%!
>emacs has regex search and replace
>I'll just filter the buffer text through a command directly
>With evil, I can even do it in the exact same way as with vim.
Boy you really missed the point here, it was just a quick way of editing the file that was /necessarily outside of the editor/.

>can't be bothered to configure emacs

>auto-revert mode
>not too much effort
>or you're not on your own system
>or you're on a new system and have better things to do than configure emacs

>it clearly notifies me

I know it does, I said it does in my post.
>finally gives me the options I need

>I implement them myself since I'm using a programmable editor

This is amopng the most basic functionality a text editor should have, it ought not be an extension. Emacs does have it but it's buried behind 'try to edit the file first and then I'll tell you' bullshit.

>Atom requires a package for this

Unless Atom treats packages like the JS world where shit like leftpad is a library this isn't acceptable. If it does, it's still fucking awful.

>Sublime can do this

You've forgotten what 'this' is, the criteria isn't "can reload files that have been changed", it is: "offers to reload them very quickly without fuss", all you've done is show me that it's possible to fuss around with emacs and vim until they have sensible defaults.

  No.16269

>>16241
Sounds like emacs buddy.

  No.16270

>>16210
PS: I do love emacs for writing lisp though.

  No.16273

Vimbros : I'd like to have something similar to Evil's search and replace (https://youtu.be/GQeDUMt0G7k?t=40s). What I mean is every instance of the regex being highlighted as I type the regex and then when I start typing the replace part it's shown everywhere in the buffer as well. Does something like that exist for Vim/Neovim ?

  No.16274

>>16273
:set hlsearch

  No.16275

>>16268
> no reason a GUI editor should do this by default

Like I said, gvim acts the same way as gedit by default without configuration, so I'm not sure what you're trying to say.

> I explicitly said in my post other editors can probably be configured to not fuck the user over by default.


Yeah you backpedalled to this. Expecting sane defaults from old-as-fuck command line editors is questionable in the first place. Not having a reload prompt right away is hardly the worst thing about vanilla command line vim.

> If emacs deleted random files from my system...


Okay right. That's comparable to not giving you a GUI popup asking you to reload a file. I get your point, but randomly deleting files is something everyone would consider bad. The default behavior of emacs doesn't bother me at all in this case.

> run over SSH in environments


Then people can use something other than vim/emacs, or they can use sshfs or emacs' TRAMP. Are you suggesting this is a reason for normally using something else even when not working under these circumstances?

> so the change doesn't matter at all

> Boy you really missed the point here, it was just a quick way of editing the file that was /necessarily outside of the editor/.

Then give one good example not covered by '%!' that would necessarily be done outside the editor and where you may want to not reload the file.

> or you're not on your own system


No one sane is going to use emacs unconfigured on someone else's system. Are you always working on other people's systems? At least realize that this isn't a problem for a lot of people.

> amopng the most basic functionality a text editor should have


Well I don't need/want it, and you still haven't given any good examples as to why it's useful.

> You've forgotten what 'this' is


No, like I said, I just didn't know whether the default is to reload the file or to prompt. I just checked, and the default is to reload the file automatically, which is the more sensible behavior anyway in my opinion. I don't know why you expect every editor to conform to your opinion of a good default for this case. These are options because not everyone agrees on what the behavior should be.

> show me that it's possible to fuss around with emacs and vim until they have sensible defaults


The idea that a single line of configuration (for vim and sublime at least) is "fussing around" is pretty ridiculous. Gvim already has the default behavior you want.

  No.16276

>>16273
See vim-over for the closest thing:

https://github.com/osyo-manga/vim-over

  No.16278

>>16275
>Expecting sane defaults from old-as-fuck command line editors is questionable in the first place.
Not him, but excusing acknowledging and accepting terrible defaults in a widely-used and still-actively-developed editor because "it's old-as-fuck" is questionable in the first place.

  No.16285

>>16278
> acknowledging
As opposed to pretending it isn't the case?

> accepting

I'm not accepting or excusing it. I'm just being a realist. For the most part, the defaults aren't that bad, but there are some cases where things are just weird (e.g. Y not being y$).

> widely-used and still-actively-developed editor

There are a lot of people writing plugins for emacs and vim, but there aren't nearly as many people contributing directly to the core development. Vim is developed mostly just by Bram, and I've only heard criticism about his workflow (tons of commits daily, tagging a ton, and basically using the master branch to experiment). I've heard a lot of bad things about getting patches accepted for both, and I imagine it would be hard to get defaults changed that have been in place for a long time in any massive, old program. It's unfortunate, but it's not a huge deal because these editors are configurable, and people have plugins for saner defaults (e.g. vim-sensible). I certainly don't care enough to start wars on mailing lists about this sort of thing. Neovim will probably be a lot better in this regard.

  No.16287

>>16274
I already use :set hlsearch. It doesn't do what I want, the regexes are only highlighted when I press enter. I wan't them to be hifhlighted from the very first moment I start typing them.

>>16276
Seems to be exactly what I'm looking for. Thanks, Lain!

  No.16288

>>16285
>As opposed to pretending it isn't the case?
As opposed to fixing it.

  No.16293

>>16288
>As opposed to fixing it.
How are you going to do that without acknowledging there is a problem?

  No.16295

>>16293
The whole point the earlier poster was making was that the defaults SHOULD be changed to "sane defaults". Then it was said that expecting sane defaults from an old-as-fuck editor is questionable. I mentioned that just accepting these defaults when the editor is still widely used and maintained (i.e., there is at least somebody capable of changing them) just because it's "old-as-fuck" is questionable. Now you've somehow got the idea that acknowledging an issue and fixing it are somehow contradictory goals. I don't know if you're being deliberately argumentative or pedantic here, but I'm getting the impression that this is the case.

  No.16300

>>16295
I am the earlier poster, and I take issue with you intentionally misusing English, and smearing words like "acknowledge" to mean "has a positive attitude towards".

The beauty of English is in it's vast and nuanced vocabulary; that which other languages take a phrase to express can often be expressed with just one word in English.

You take issue with, in your own words, "[people] excusing acknowledging and accepting terrible defaults".

There is absolutely nothing with with excusing acknowledging terrible defaults, nor even with acknowledging terrible defaults.

  No.16301

>>16300
Okay dude, you're obviously just interested in pedantry so I'll stop wasting your time now.

  No.16303

>>16301
No, I really don't give a shit about the minutiae of grammar (hence my cocking-up "its" in that post, and refusing to put final punctuation inside parens because it looks like an overlapping hierarchy).

The only thing I care about is having a rich standard library of words to work with.

English isn't set in stone, it's defined by how its speakers use it; thus anyone who cares for it has an interest in how others use it.

It might initially seem to be pedantry, but consider that nowadays definitions have so slipped that people will infer from the following statements that one has a positive view of Hitler or the third reich:

Hitler was a great man.
I respect Hitler.
The rise of the third reich was awesome.

How absurd a situation that people would think a person uttering any of these approves of Hitler or the third reich; this is how far these words have slipped into being meaningless blurs of positivity.

  No.16304

>>16301
>>16303
P.S.: This is the same bullshit that killed the word fantastic and necessitated that abomination that is "fantastical", with what "fantastical" ought to mean presumably being now represented by "fantasticalal" (which of course it isn't, we just don't have a word for that concept in English now).

"grotesque" is also dead now, with no replacement; another concept we can't express in a single word.

  No.16307

What happened to "grotesque"?

  No.16308

>>16307
In British English — in my experience — it has come to exclusively mean "disgusting", sans the moral connotations.

It has lost any descriptive power, and now merely reports ugliness without any explanation or implication of the reason for the ugliness.

  No.16309

File: 1462924345912-0.png (80.74 KB, 151x200, Grosmith.jpg)

File: 1462924345912-1.png (132.51 KB, 200x161, serveimage.jpeg)

File: 1462924345912-2.png (175.31 KB, 200x113, serveimage2.jpeg)

>>16307
>>16308
PS, here's an example of where it has a significant effect.

The first image is a weathervane taken from the wiki article on grotesque. If I want to describe it now (in Britain at least) I can't call it grotesque, but that's ok because I can still describe it as a deformed seahorse as it deviates from the archetype.

The second image is a centaur, and I certainly can't call it deformed because it doesn't deviate from the archetype. That's ok though, I can call it aberrant because it deviates from nature (albeit nature is only implied as the standard, but in this context it would be understood in this way).

The third image is a goblin shark, and I certainly can't call it aberrant because it's not very far from the norm for such creatures.

What I need is a word similar to the previous two, but without the restriction of having to deviate from a standard. I'll grant this is a somewhat contradictory definition, but hey, natural language is hard to pin down precisely. Previously the world "grotesque" would have been used here to describe the /form/ rather than as a judgement of beauty, though with the right tone a judgement of beauty could certainly have been easily implied.

The fourth image is grotesque, but not deformed, aberrant, or ugly.

  No.16310

File: 1462924367730.png (78.57 KB, 162x200, serveimage3.jpeg)


  No.16311

>>16309
>>16310
Oh, I forgot to make my damn point.

All four are grotesque, and three of them are now significantly harder to succinctly describe as a result (three because aberrant doesn't exclusively imply a deviance in form).

  No.16312

As an example of English's rich vocabulary: the following words are all different ways of asking someone to do something.

ask
request
demand
importune
beg
entreaty
enjoin
direct
order
require
appeal
implore
petition
command
bid
call
plead
solicit
proposition
suggest
sue
pray
beseech
exhort
urge
incite
counsel
enjoinder
dare
invoke

While any language you pick will have words for some of these, and probably words for variations we don't have words for in English, few languages will have so many options with so many subtly varying connotations.

The important thing is though, that this isn't some corner case of English; it's the norm to have such detail in single words.

English isn't alone in this, but it is without a doubt among the best. The OED contains over 600,000 words, and English has a strong stylistic taboo against repeating words in close proximity because we can afford to do so without resorting to pro-forms.

  No.16313

>inb4 quibbling over what defines a word

The value is largely in connotations, I don't have any real attachment to using the word "word" to describe "the smallest unit of meaning with unique connotations".

If you don't feel the word "word" is appropriate, feel free to find another and reread my posts substituting your expression where I say "word".

  No.16314

File: 1462927917241.png (235.63 KB, 200x150, Canon_Cat.jpg)

>>16308
>>16309
>>16310
>>16311
>>16312
Your posts are very pleasant to read. I simply go the route of attempting to use each word by its actual definition, regardless of how it's now commonly used.
I suppose my linguistic efforts are evenly divided between exact and interesting phrases and words, in place of focusing on words more.

It's nice that the computing vocabulary is still fairly open for shaping and coining, while also being in a position that leads to proper usage of many of the terms.

Anyways, this is still the editor thread, so I'll bring up the Canon Cat. I've been considering purchasing such for quite the while now, but don't yet want to spend near $1,000.

Has anyone here used a Canon Cat?

  No.16315

>>16314
It looks nice, but I can't help thinking it's a bit pricey.

Have you considered using https://github.com/Swordfish90/cool-retro-term on X without a WM?

Because it's the only X program running you'd be free of distractions, and if you started it with "&& exit" then closing the editor would log you out ensuring you could never get distracted.

If you're logged in, then you're in the editor. Close the editor, and you get logged out. Having your computer boot into the editor, and shut down on closing it wouldn't be hard either.

http://www.embedded-bits.co.uk/2011/1-second-linux-boot-to-qt/

Run it on an old CRT with a nice mechanical and you're half-way there. Now you just need a good editor, cool-retro-term will run any normal terminal program, including ncurses, &c.

  No.16316

>>16315
I'm not certain you understand.

The Canon Cat was a specialized computer system programmed in Forth. It was designed by the late Jef Raskin, an expert on computing interfaces.

From what I've read, the entire system was optimized for writing. It included a dictionary with near 100,000 words, along with writable dictionary space for the user to customize.

The keyboard is also specialized for this purpose.

Here's a website:
http://www.canoncat.org/

I hate using UNIX, doing almost everything in Emacs. I want to push my computing away from a UNIX and PC. Computing is so much more than what most people are able to use and I hate that.

I'm already taking an effort to move myself away from UNIX, so this would simply be another step towards that. I feel that I must protect myself from UNIX, lest I begin to lose the idea that there are other and better ways to compute.

I want to innovate in computing and UNIX is among the worst environments for that.

  No.16318

>>16316
So are you using emacs without a WM?

I never figured that out. Since I disable all the bar modes, it just leaves this extra space at the bottom of the emacs window that I can't get rid off unless press F11 twice. And yes, I do have the -fs flag set.

  No.16319

>>16318
>So are you using emacs without a WM?
I usually use StumpWM so I can have multiple frames and Emacs instances that can be easily switched between.

>I never figured that out. Since I disable all the bar modes, it just leaves this extra space at the bottom of the emacs window that I can't get rid off unless press F11 twice. And yes, I do have the -fs flag set.

You can store the fullscreen commands in your .emacs to make it more convenient.

  No.16321

>>16319
>You can store the fullscreen commands in your .emacs to make it more convenient.
Yeah, I tried that, but unfortunately it's even dumber when it comes to that. It just doesn't resize at all in that case.

Guess I'll just need a WM and not use it at all.

  No.16325

>>16316
Ah, sorry, I thought you were trying to escape distractions.

Thanks for the link.

  No.16327

>>11855
vim does have a daemon mode tho, or at least it can be run as a server.
>>13552
I use emacs heavily, but not for reading pdfs. I use zathura for that which has some nice vi-like bindings. I open pdfs through emacs though with some package like external-program or something. It just dispatches to external programs depending on file type

  No.16334

>>16327
I use zathura as well, but pdf-tools with evil is really more vim-like. You can open pages in a text buffer and use evil to copy things, for example.

  No.16340

File: 1463064871781.png (42.6 KB, 183x200, errors.png)

My emacs does not display special chars , anyone have any clue?

  No.16341

>>16340
I've only experienced this on a BSD.

I was having many font issues on that system.

What system are you using?

  No.16342

>>16340
...Are you running emacs on your phone/tablet?

  No.16344

>>16340
I nearly failed a uni assignment because of this shit when the output was all messed up. I don't know how to fix it though and opening it with other editors didn't help. Had to frantically install a windows VM.

  No.16349

>>16340
>Having a 46 pixel titlebar
What the actual fuck?

Unless you care about the title of the window, titlebars are utterly worthless; a 46px one is just a damn joke.

>close windows

Key-bindings are far more convenient.

>move windows

A key-binding that lets you click-drag any part of the window is far more convenient.

The only possible reason to have title bars is for decoration, because you think they look good somehow, and even then 46 fucking pixels on decoration?

Your request looks automated; Post discarded.

  No.16392

Most Linux distributions have jed in their default repository, but I have never heard anyone aside from myself that uses it. Am I alone? I keep telling myself I will switch to emacs, but it has yet to happen. Lots of similarities though.

  No.16479

>>16341
Ubuntu
>>16342
No. Why do you ask

>>16344
I figured it out guys , the default system coding was not set to utf8 for some reason
adding that to .emacs fixed it.Thanks

  No.16480

>>16349
Oh yea never got around to changing the title bar tbh.
Fixed that as well.

  No.16482

>>16479
I thought you might be on a mobile because of the way the top bar looked and incorrect encoding.

  No.16560

Has anyone worked with any of the Emacs starter kits? I've been thinking about them recently, and think they might be a good idea. Emacs is an incredibly flexible editor and has a lot of useful applications written in Elisp, but the defaults are pretty damn bad and it practically requires configuration and extra packages for doing anything much more basic than editing unstructured text and parens (even SLIME requires setting up MELPA). Similar to how Lisp-language's flexibility makes them great for DSL's to handle specific tools, I think Emacs could be great for DSE's, or Domain Specific Editors. I'm really fond of the idea of Emacs becoming a sort of foundation for other editors. We're already moving in this direction with the way people tweak and then host their own .emacs configuration.

I appreciate the flexibility and configuration Emacs offers, but I also understand the desire to spend more time working and editing than working on your editor. Not everybody wants to treat Emacs as a hobby instead of a tool that requires the minimum effort of maintenance and setup. There's a lot of times where I wished shit "just worked", instead of requiring me to download, configure (and inevitably, due to some mistake I made), debug packages while overloading my .emacs file with complexity.

I've been using Spacemacs now for a while, since it has a mode for default emacs keybindings and has a lot of convenient key-bindings, but I've found that I don't really take too much advantage of its Vi-focus, and its convenience comes at the cost of of ease-of-configuration and updating (modifying the default configurations of packages requires you to host them in a "private layer" and modify them yourself, or clone the project and run all modification through git and deal with potential merge-conflicts from updating).

Here's some emacskits, if anyone's interested:
>spacemacs
>emacs 24 starter kit
>graphene
>cabbage
>prelude
>Steve Purcell's .emacs.d
>oh-my-emacs
>

  No.16581

>>16560
I use spacemacs. I like vi-style editing, and the package management is godlike.

  No.16582

>>16264
>that syntax
Wish I had a pdp-6

  No.16583

>>16316
TempleOS might do what you want lol

  No.16588

I use vim for Java and tex, but I've been thinking about switching to Emacs for CL.

  No.16599

>>16392
An old perl hacker at my work uses Jed, and a lot of top developers like Linus, Theo de raadt, Alan cox, while they may not use Jed, they all use simpler editors like mg etc and just write code without needing the latest emacs/atom build and 400 plugins

  No.16600

File: 1463837937194.png (45.44 KB, 200x200, huong-dan-cai-dat-Visual-Studio-Code.png)

Microsoft's Visual Studio Code is actually pretty good. I prefer it over Atom and Sublime. Atom is just mindbogglingly slow and Sublime needs monies and seems to have very stalled development. VSC starts fast, loads files fast, has no trouble with large files, is quite easily configurable with text file like Sublime and Atom, has decent git integration and even plugins which I learned just this week. I'm also fond of the colour schemes. Can't think of any real downsides compared to those other two. Anyone else using it?

  No.16602

>>16600
I try it on and off, it's definitely faster than atom and feels pretty comfy

  No.16604

>>16600
Sublime is still actively developed and gets regular (weekly+, iirc) updates. They're just on the development branch.

  No.16616

>>16599
Because they learned on those editors.

  No.16630

>>16599
Others like john carrmack use massive IDE's like Visual Studio. I dont think the text editors good programmers use is what makes them good programmers.

  No.16632

>>16599
Knuth uses emacs. :)
It's not the text editor that defines your abilities.

  No.16637

>>16602
Atom on linux works pretty good. To me it feels just as it did Sublime back in the day.

Atom used to be sluggish, but it has gotten a lot better with time.

Can I try M$ Code in linux?


  No.16651

>>16241
gnu zile is maybe what you mean. it's a text editor development kit written in lua.

  No.16676

After a couple years with Emacs, I recently switched back to a native editor of local significance (Geany, currently).

Emacs is too general and I fear it. Vim wants me to type in a weird way and I'm not interested in that. Atom wants me to abandon all decency and surrender myself to the sea of DOM and XHR, and I'm just not ready for such a leap of faith. Maybe in a few years, when it's all WebAssembly.

I still use Emacs for the Org mode, of course.

  No.16678

>>16676
>Maybe in a few years, when it's all WebAssembly.
it's just a matter of time before computers are nothing but web browsers, running OS.js and having no disk storage because everything will be on the cloud.

  No.16679

>>16678
I think the industry is in good enough shape that the architecture of this new thin client will evolve to be something sounder than just Chrome slapped on top of a kernel.

When I close my eyes, I can see HTML and JS fading away to leave DOM + standardized APIs to various features + a delivery/sandboxing mechanism, all programmable in any language and compiled down to native. I think I could live with a platform like that.

  No.16685

>>16679
I read this on a tablet, and I think it's not too bad an idea. If we can hope that ASM.js doesn't stick to bullshit just to comply to what's there right now for the sake of stupid devs (which are far too many), and if we could get rid of java altogether, if just for the sake of making things if only a bit better...
If a good enough virtual machine is devised such that a wide class of languages can be compiled down to it's bytecode, then, yes, a sound system can be then built around it. I'm thinking about tablets and phones and something similar to how the dalvik machine runs on top of little more than a linux kernel on such devices.
I can picture that: a handheld web browser, with a virtual machine for which devs can write in their favorite language. Would that be too hard?
It would be kind of like a little hitchhiker's guide to the galaxy.
I have my tablet where I read pdfs and browse wikipedia and I am amazed often as to how in the present day we're trying to recreate all this dank stuff from sci-fi, such as video calls, virtual reality, holography, and we've already recreated the best of it all without even noticing (again: the hitchhiker's guide)

  No.16688

File: 1464165263551.png (10.15 KB, 200x85, 1464165228.png)

Micro is the best text editor

>Easy to use

>Common keybindings (ctrl-s, ctrl-c, ctrl-v, ctrl-z...)
>Extremely good mouse support
>Search and replace
>Undo and redo
>Copy and paste with the system clipboard
>Small and simple

https://github.com/zyedidia/micro

  No.16689

>>16688
>it is the best
>lists downsides

  No.16692

I'll get sick of vim, but then I use something else and feel crippled without the power of :g,:s etc commands and go back to it when I need to do some non trivial substitutions

  No.16703

>>16692
Not if you switch to emacs with evil.

  No.16732

>>16689
>implying best means perfect
Buy a dictionary nigger.

  No.16738

>when you start using vim your productivity drops significantly, but after a few weeks it's bounced back to normal levels or higher

I don't believe it. Are there any studies that prove that vimfags are more productive than people who use a normal GUI editor, like Sublime?

Answer: nope.

In fact...

>We show that Vim users were slower than Emacs users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert Vim users performed even worse than novice Emacs users. Vim users, however, more often report enjoying using their respective software. We conclude that even experienced Vim users may suffer a loss in productivity when Vim is used, relative to other text editors.


http://mjambon.github.io/vim-vs-emacs/

I hate emacs too tbh. Cording is fundamentally a shitty thing to do on the hands. There is literally no reason to use anything but a normal GUI text editor, or a terminal equivalent that isn't vim/emacs.

  No.16739


  No.16741

>>16738
Algorithm analysis m8.

Let's say we want a generalized algorithm for a task A.

Sublime/Gedit:
1. Move hand to mouse
2.Click on menu
3.Select from menu
4.Move hand back to keyboard
5.Type in *whatever*
6.Press enter

Emacs/Vim:
1,2.Type the command say 2 keys <esc> in vim plus some command and <C/M> in emacs plus some key.
3.Type *whatever*.
4.Press Enter.

Note: This is generalized if you wanted you could even bind the most used commands to whatever is comfortable.

  No.16742

>>16741
> Let's say we want a generalized algorithm for a task A.
Except we don't, and your analysis is moot. 99% of the time you use a fixed set of commands.

  No.16744

>>16742
Yes but with a generalized one you can prove that always emacs/vim will be better than GUI

  No.16745

>>16741
Why do you separate all of the mouse related tasks into separate ones? It's just one step:
>select with mouse
You could do the same with vim, but the truth is that "microsteps" are chunked as one single step.
>check if you're in insertion mode
>if you are, move your hand all the way to escape
>Click it.
>move your hand all the back down
>enter your command sequence
>hit enter
>go back to insertion mode if you want to write more text
What you posted wasn't even an "algorithm analysis". In addition, all of those editors support binding and macros.

I also use vim and emacs, but sometimes you guys make really ignorant arguments in favor of them.

  No.16746

>>16744
Look wtf

Never mind reality, with these contrived variables dialed just so, I can prove almost anything

  No.16747

I don't get the people who defend these training wheel editors.
Do you really like to move your hands away for the keyboard all the time?
I personally cannot stand it, having my workflow interrupted by actually having to move away to do something I could do with the keyboard. For example, getting back to the beginning of the line. If I am at the middle of something and decide I want to add something before that I can just C-a <RET> in emacs and I have a newline before the one where I was typing, in vim I can jjO (I have do an <Esc> in Vim so my mode switch is swifter) and I have the same effect.
That's just one example. Deleting a whole line, a sentence, changing case in a character, jumping to a matching paren, repeating a command, performing a s///, finding a match (just think how much work it takes to go jumping to a menu to get the 'find in document' option when you could just type jj/searchstring ). I often have line numbers in my editor so I can type 77G if I want to go to line 77.
I can only imagine how frustrating it would be walking around the room just to do those tasks. I get annoyed about having to do such things in the web browser when shitposting on cambodian turban design forums.

  No.16748

File: 1464465777258.png (485.51 KB, 153x200, 5a5fe075dd24d8014dffdd27791f46f99bd7ac37.jpg)

"Editor wars", not even once.

  No.16749

>>16748
This entire thread is painfully autistic, especially with that bizarrely out-of-place multipost complaint about the state of grammar. Yeesh. I thought people trying to turn discussions into arguments about grammar was just a joke.

  No.16752

I think Vim's editing style is a more enlightened approach, but I wish my computer was a Lisp Machine, so I use Emacs, albeit with a hacked together modal configuration.

I wish the Vim idea was taken much further, where editing could be defined as actions performed on a set of semantic units. You should be able to use the same action, like delete, select, or something more complicated like transpose on an arbitrary number of any kind of textual element, be it a word, paragraph or s-expression.
These textual units should also be definable by the user through a means like regexp, and used as primitives for manipulation. So in command mode I could say db3^, where I've made a definition for any kind of unit I'm working with and bound it to caret, and have the editor delete backwards 3 <units>.

I would like to write my own text editor at one point, but I'm not up to the challenge yet. I think the above could probably be implemented in Emacs Lisp, and I've been planning on studying Evil's source to figure out how it should be gone about, figuring out how to define semantic units and have them work with existing functions will be the hardest part.

  No.16755

>>16747
IMO programming these days involves not a lot of typing, so I don't really see the problem with using less convenient text editors. That said, after I got used to Vim I quickly realized that using any other editor would be annoying, so I understand your confusion, but it's really only annoying if you've realized how nice it can be. When I tell beginners what to focus on I *never* tell them to learn a convenient editor, if only because they won't think they're a Real Programmer until they do (which isn't true at all).

There are Vim plugins for most popular web browsers, if you're interested in that! I've never used one though, I just write things in my text editor then copy them in.

>>16752
I like the idea about semantic units and generalizing actions to work on more things than just text. Allowing the user to define what a semantic unit is from the ground up would make me very interested in your theoretical editor.

My suggestion is to write a small text editor. Programmers have a bad habit of thinking that eventually they'll be smart enough to tackle the problem, but because they aren't they should do something else before tackling it. (I think we tend to be perfectionists, especially with our code, and thus procrastinators, but I digress.) The proper way to attack learning how to write something like your interesting text editor (besides reading about how to write that something, which is what you want to do for very hard things like Chess engines, operating systems etc.) is to write a boring version of that thing first. For example, if I were you I'd try to write a basic version of ed, then maybe vi. Don't worry about incorporating the hard parts of your idea yet, just get something small done, and build up to your complete idea. You'll keep thinking about semantic units and such while doing other things, and probably have some breakthroughs that way. Try to make your problems as simple and non abstract as possible and you'll make good progress in solving them.

  No.16758

>>16755
>IMO programming these days involves not a lot of typing, so I don't really see the problem with using less convenient text editors.

This. I don't see the problem if you have to move away from the keyboard or how much you have to move your hands. When programming I need most of the time for thinking. So my editor of choice doesn't matter that much. I am able to use Emacs and Vim and the standard editors but at the end of the day they are just tools and I don't really care that much about them.

Of course, that is my style of programming. Some people might be more comfortable with experimenting, writing code, deleting code, refactoring alot etc. In this case typing speed might matter more.

  No.16767

>>16745
Ctrl+left square bracket is the same as escape, but a lot of people rebind escape to capslock

  No.16784

File: 1464690483488.png (201.73 KB, 150x200, 1414647446410.jpg)

>>16749
>multipost complaint about the state of grammar
>>16303
>I really don't give a shit about the minutiae of grammar

>posts about a process within semantics and the importance of a rich standard library

>complaints about posts about the current state of grammar
The irony is exemplary and disheartening.

  No.16790

>>16752
>You should be able to use the same action, like delete, select, or something more complicated like transpose on an arbitrary number of any kind of textual element

Text objects can take counts and are definable with regexps (at least in evil). What is wrong with them? If you want to delete in a direction, you use motions. What is wrong with motions? It's easy to create new motions and text objects. As for transposing, the vim and evil exchange plugins allow you to swap text objects. If you're swapping the same type of element, you only need to specify it once, and then you can use the dot command at the other location.

> figuring out how to define semantic units and have them work with existing functions


How are text objects not semantic units? There are already both motions and text objects for words, paragraphs, and s-expressions.

>>16755
>more things than just text

What does that mean?

>Allowing the user to define what a semantic unit is from the ground up would make me very interested in your theoretical editor.


What is wrong with the way vim and emacs do it? Granted, even with vim-textobj-user, I think making new text objects with evil is a lot nicer, but it's still possible in vim, and there are quite a few plugins for both editors that provide extra text objects.

  No.16791

>>16784
>shitposting

We don't do that here.

  No.16792

>>16791
I don't think you know what that word means, my sweet summer child.

  No.16796

File: 1464732524116.png (116.96 KB, 200x109, serveimage.jpeg)


  No.16800

>>16784
Sorry if I touched a nerve there, but I definitely count at least 3 posts complaining about language (>>16300 >>16303 >>16303 >>16304), and 4 after that going off on a tangent about the word "grotesque" and the english language in general, including a 30 line enumeration of different ways to ask someone to do something.

  No.16805

M-x please-return-to-discussing-your-editors

  No.16903

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

I'll probably start working on the Guile-Emacs integration soon, which was brought to a quite advanced state by the amazing Robin Templeton (aka bipt or bpt), but has been dormant since.

This project does not aim to replace Elisp. Rather, Guile is capable of running Elisp and Scheme on the same platform. Details:
https://www.emacswiki.org/emacs/GuileEmacs

  No.16906

>>16790
>How are text objects not semantic units? There are already both motions and text objects for words, paragraphs, and s-expressions.
They are, the point is that other things are semantic units too (images, for example). Treating these things in a uniform manner would be interesting.

>>more things than just text

>What does that mean?
Like I mentioned, images, also audio or other binary data, or items in a list, etc. (that is, you could define a collection of semantic units to be a semantic unit). You can emulate this with Elisp and rebinding keys but this would be a more elegant solution.

>What is wrong with the way vim and emacs do it.

It's not as general as what I had in mind, at least, and the editors aren't built from the ground up with that in mind.

  No.16925

>>16340
>>16341
this looks like a LOCALE issue. you have to set your LOCALE env variable and have the proper LOCALES generated, or things will default to the C locale and not use beyond the base 256 chars.

how to manage this is different on every system, but search around and you'll figure it out. things with systemd use localectl, because systemd eats errythang

  No.16928

>>16903
Guile 2.2 has full elisp support doesnt it?

  No.16929

>>16928

bipt's branch does. Not sure if merged yet.

Also the Elisp in Guile itself lacks all the Emacs data types like buffers and windows. Guile-Emacs does it so that the C code of Emacs that originally defined those types for Elisp now defines them in a generic way for Guile, so both the Scheme and Elisp worlds can use them. Emacs basically becomes an application that uses libguile, defines its own data types, and rather uses Elisp than Scheme for its libguile-powered scripting interface, so to say.

  No.16931

File: 1465141848146-0.png (203.7 KB, 200x110, swap.webm)

File: 1465141848146-1.png (337.17 KB, 200x110, gather.webm)

File: 1465141848146-2.png (380.98 KB, 200x110, align.webm)

Here's one that looks intriguing and most people probably haven't heard about: http://kakoune.org/

  No.16954

Has anyone here attempted to use Emacs as a web browser?

How capable is it of handling the mess of javascript and css that is the "modern web"? Or is that feature set meant only for rendering plain html into text?

  No.16955

>>16954
I may be wrong but I don't think emacs can deal with javascript (elinks can, though). Fortunately enough, most of the interesting websites out there do not rely to much on Javascript.

  No.16960

>>16954
Emacs-W3M works well for text-only. I don't use it regularly but it comes in handy sometimes.

  No.16963

>>16954
Emacs 25 will support webkit, so you will benable to access the full web that way.
Be warned though, webkit is a horrid mess, and it has known security flaws all over.
I personally think it's stupid, I'd raher put the kernel in there first

  No.16966

>>16931
Thank you for sharing, it looks great

  No.16980

I'd love to learn me some acme, but I can't really find any good "tutorials" except the Russ Cox video. Not sure how to have an acme setup for c (what windows to have, best practices and so on) and if it supports sending things to repls if i wanted to try some lisp/scheme

  No.17075

Geany.

  No.17766

I use GNU Emacs. It's nice. I customize it and use it for increasingly many tasks.

I really want to switch to an Emacs written in Common Lisp, but I've not bothered with it yet.

I generally believe that an editor written in a language will be able to provide a better environment for that language. This is mostly because the languages I use have environments and so would be able to natively understand and manipulate programs in-development in a better and more structured way.

I'll do something with these ideas one day.

  No.17767

so write an editor in CL? writing an editor is and always will be an excellent programming exercise.

  No.17793

>>17767
>>17766

the best lisp IDE is graph paper and pencil

>0 memory or electricity cost

>crash-free
>secure
>persistant
>stop fucking up your hands with a keyboard
>a mouse is a poor imitation of this
>encourages proper glyph/code compression abstraction, you will eventually roll out a calligraphic DSL or turn your programs and ideas into art

  No.20483

I'd like to learn more about TECO, but that seems like a waste of time.

  No.20490

File: 1480224898245.png (316.46 KB, 200x114, gregg-shorthand-example.png)

>>17793
>encourages proper glyph/code compression abstraction, you will eventually roll out a calligraphic DSL or turn your programs and ideas into art
I feel silly saying this but that actually sounds amazing. Alternatively I feel like a shorthand DSL would be neat for quickly getting ideas out by hand. Write an image recognition program in Lisp and scan programs into a repository (but not before sketching out the program in your shorthand DSL!)

  No.20491

I use MS VirtualStudio for windows drivers, it's a really smooth IDE.

Otherwise vim with a few plugins.

  No.20495

>>11780
>>11877
This. Textadept is a lot faster and lighter than Gedit (especially the JIT version) while still wrapping Scintilla, the text editor component of Notepad++. I use it when I have to work on small things and it does its job egregiously.

For large projects I use full featured IDE's, like QtCreator or JetBrains's various products.

  No.20562

>>11770
What is your keyboard like?

  No.20569

>>11834
Emacs has bad keybindings IMO so you should use Evil. Emacs itself has some bad parts but it's better than any editor because it is fundamentally a simple C implementation of Lisp combined with a lot of Lisp. It is completely hackable from the ground up while being easy to understand. Stuff like why it gets unresponsive at certain times is really because of its trouble with async. This is one of its worst weaknesses in my opinion. The problem is that other editors don't even attempt what Emacs has done (with some exceptions-- Emacs is the largest and most "featureful" of its bunch). Once you understand where Emacs stalls it becomes easy to mitigate it, but I agree that it's a bad part of the editor.

  No.20570

>>20569
Sorry to respond to a very old post btw I just thought it was an interesting/common opinion.

  No.20761

>>20569
They are testing concurrency now so some of the slower packages may speed up in the future

  No.20762

>>11752
my nigga

  No.20763

I've been toying with the idea of making a text editor with the same general idea of emacs, but with a different scripting language than elisp. Not sure what language to use, though.

  No.20775

>>11752
I was going to mention sam, it looks so sexy. However there is no port to it for my system.
Maybe I should try to do just that.

  No.20776

>>11743
i just code in leafpad. Is that normal? I don't need anything fancy, just leafpad and an ide.

  No.20777

>>20776
I use vi.
Source code is plaintext.

I found this yesterday, it's somewhat related https://blog.interlinked.org/programming/texteditor_code_generation.html

  No.20778

>>20776
Personally I like being able to look at a word and immediately jump to it with a couple keypresses instead of using a mouse, but what works for you works for you.

  No.20779

I use Sublime Text because I think it's enough for what I do

  No.20788

File: 1481757092456.png (2.6 MB, 200x110, Untitled.png)

>>11743
>tfw you transcend the vim/emacs debate and embrace the Atomic Age

  No.20789

>>20788
Atom is dog slow thanks in part to Electron, Node and soykaf praxis. Its extensions are a joke: case in point, vim-mode and ex-mode which are practically useless, and you are locked into writing extensions in the toy language JavaScript or one of its bastard offspring, with inadequate APIs compared to Emacs. Rising out of the atavistic anarcho-capitalist GitHub/HN ideology, it even goes as far as to collect "metrics" by default and scoop up uncaught exceptions without informing the user. Atom can't be easily used remotely and can't be used in a terminal. Most shockingly Atom is even bested by an editor that runs on its own mistake-enabling spin-off Electron, VS Code, which is made by Microsoft of all organisations, not to suggest however that it too isn't liquid soykaf.

  No.20790

>>20789
I've been working in tech for going on 6 years now, I've just never run into a use case where any of what you brought up is really relevant, though. I'm by no means l33t, but I've made a career of it, and Atom is great for what I need.

99.9% of the time, I'm going to write stuff, smoke test it locally using the embedded shell, and then push to where I'm deploying and trigger the deployment through the tabbed ssh shell.

I guess I'm curious- what kind of extensions are so great that you would sacrifice the ability to have an all-in-one IDE that you could rice to hell and back? The only thing standing between me and having a single-window cross-platform UI with consistent look and feel is figuring out how to embed Atom in a Vivaldi pane, and I can't think of anything cooler than that, really.

  No.20791

Emacs with spacemacs and nothing more.
I'll use eclipse for java.

  No.20792

>>20789
JavaScript isn't a good language, but it's definitely better than VimScript, and it's better than elisp too. I use emacs after transition from vim and this is my honest opinion of the editors scripting language. You can dislike Atom and JS as much as you want (I dislike them both as well), but whether JS is worse than VimScript or Elisp is a totally different topic separate from whether their respective editors are different.

  No.20797

I was a vim user, now I use Emacs + evil-mode.

A bit of advice for people wanting to learn Emacs:

IGNORE ALL PLUGINS. Except maybe evil-mode and paredit.

Why? Open Windows Notepad. Look at all the options in the menu. Do you understand what they all do? Yes, because Notepad is simple and has no features. Now imagine that you add one feature to Notepad, then learn it. Like, say, navigation by sentence. Then add another, and another, building on your current knowledge.

Think about the first time you opened a large, complex IDE. How long did it take you to understand what every option in the menu did? Do you understand half the options in Eclipse, NetBeans, or Visual Studio?

Emacs has a learning curve, but by itself it's not that bad. Keep the manual handy and learn the stuff in it. When you find you're really wanting one particular feature, then sure, go ahead and add it.

Once you're really comfortable in Emacs, then you can start adding plugins willy-nilly. Until then, all you're doing is making the learning curve that much steeper.

  No.20819

>>20797
to be fair though, GNU documentation is some of the worst i have EVER read

you're better off learning emacs by simply experimenting

  No.20842

>>20790
>I've just never run into a use case where any of what you brought up is really relevant, though.
I don't need any fuarrrking "use cases". If anything, my use case is editing text. You sound like the libinput developer who had no clue why anyone would ever want to disable pointer acceleration.
>slow
Surely this is the most important thing you want from your editor. Waiting on your editor when, for example, you're typing, is something you NEVER want your editor to do (or any other application for that matter). You want files to load semi-instantly.
>JavaScript
Running a whole web browser for your editor means you can never be sure it isn't going to run off and do something in the background without you asking; besides, running in a browser means you get another massive browser process (or processes) along with the actual web browser you are invariably also running and makes Atom consume battery life like a dog (yes, it IS important).
>metrics
Considering you use Vivaldi I assume you have decided to put your fingers in your ears, scream LA LA LA and pretend it doesn't happen.
>the embedded shell
Unrelated to my other points, but WHAT fuarrrking embedded shell? I couldn't find one and all I found was a crippled package that barely worked.
>what kind of extensions are so great that you would sacrifice the ability to have an all-in-one IDE that you could rice to hell and back
I already have an "all-in-one IDE" editor that I keep around, it's called Emacs, and even Elisp is more efficient and light than JavaScript. It's just as, if not more cohesive and integrated an experience as Atom.
>>20792
Yes, I too think VimScript is an inadequate language, which actually leads me to be impressed by the inventiveness and resourcefulness of Vim plugin developers. I disagree though that JavaScript is better than Elisp; Elisp lacks many of the utter failures of JavaScript, the language designed in ten days (weak but dynamic typing, single number type, Object/hash-table stupidity, four ways of iterating over a list) and the Emacs runtime is just simpler and more efficient than any JavaScript runtime. Look at the CPU usage of Emacs compared to Atom, and more importantly the sheer difference in SLOC between Emacs and Atom, Electron, even just V8 itself: it's unmistakable that Emacs is just simpler than Atom.

  No.20865

File: 1481945101141.png (6.35 KB, 200x116, 1473828226342.png)

>>20792
Lisp programmer here. Emacs Lisp is nicer than JavaScript.

  No.20868

>>20819
>to be fair though, GNU documentation is some of the worst i have EVER read
This isn't the first time I heard about this, so could you elaborate? Is because the info format (unnecessary complex) or is the content itself?

  No.20869

>>20842
I'm not throwing shade or anything-
if emacs fits your use case, that's great. Text editors are all about personal taste.

>slow

I'm running on 32GB of memory, running 4 or 6 instances of vivaldi plus 3 virtual desktops and an atom instance, very stable.

>Javascript


yep, agreed. but I'm wired at work.

>embedded shell

It's like the second terminal emulator down on the plugins list- I forget which. I'll bump when I remember. my big issue is that the up arrow doesn't line scroll, so I don't use it for development, just invoking bash scripts.

>I've just never been able to get emacs or vim feeling anywhere near as good as atom does.

  No.20870

File: 1481985808627.png (32.74 KB, 111x200, funny-picture-1332255548.gif)

Sorry in advance if not quite right place for this little question, but felt reasonably relevant here.

Non programmer - keeps seeing emacs vim etc. talked about as "text editors" - are these just straight up text editors or are they some magic tool for programmers? What do these do that say LibreOffice does not do? How are these tailored to programming?

  No.20872

>>20865
I'm also a Lisp programmer. I just think elisp is like kicking dead whales down the beach.

  No.20874

>>20868
it's a bit of both

the former can be fixed by using HTML versions of the manuals but the content is so badly written, it's nothing but useless details and nothing is ever concise

  No.20875

>>20870
At their very essence, from simple text editors like nvi, sam and nano to larger extensible real-time editors like {Neo,}vim, Emacs, Atom and also big bugger IDEs like IntelliJ IDEA, Eclipse and Visual Studio do the same three things (or just the one if you like): open, manipulate and write buffers of text, where text is a collection of characters.
Text editors also give you commands to manipulate your buffers of text and visual editors (everything except ed) let you move your cursor around. Extensible editors usually have a whole programming language runtime inside them; Emacs has Elisp, Vim has its own VimL as well as supporting Python, Ruby and Lua, Atom being a special case as it is written in JavaScript along with HTML and CSS. You either get editing primitives and build plugins on top of them, like in Vim, or you get programming primitives and build an editor on top of them, like Emacs and Atom.
What matters, then, is what LibreOffice does that text editors don't do. LibreOffice operates on a buffer of text at the lowest level, but what you're typing into is treated as a piece of paper and you get all the formatting information along with it. Compilers and interpreters want just streams of bytes that translate to characters.

  No.20876

>>20870
Emacs/vim and the rest *are* just text editors. Real text editors, unlike, say, LibreOffice or Word, which edit XML ($WARDING_RITUAL_INVOCATION) document detailing typesetting information (font size, font, color, etc.) and other such nonsense, edit raw ASCII character streams (or, in these enlightened times, UTF-8), the format accepted by most compilers/interpreters (unless you're writing in an ancient dialect of APL, programming in Fortress, or writing on an old IBM system that expects EBDIC ($STRONGER_WARDING_RITUAL_INVOCATION)).

However, they are also programmer's editors. That doesn't mean they can't be used for ordinary text, but they provide additional features of use to programmers, like syntax highlighting, autoindentation, brace/paren matching, scriptability, Piping and other UNIX interop, ctags support, and (perhaps most importantly) support for regexes.

  No.20881

File: 1482028123415-0.png (114.15 KB, 200x171, zenergy-enlightened-matter-modern-art-work1.jpg)

File: 1482028123415-1.png (281.53 KB, 200x146, 1280px-Periodic-table-chart-of-popular-type-typefaces-fonts.jpg)

>>20876
>>20875
Thanks for nice info.
So all you do is type in say emacs then output to a compiler of your language and bam you have an app... or is it more pain than that to go from code to app??

Not wanting to derail this thread, this could be a relevant tangent - what screen fonts/size do you guys like to use for programming? Can/do you adjust the line spacing and letter spacing for nice sweet screen display? Do you have one preferred screen font that works well on Mac Win Linux for cross platform work?

  No.20883

>>20881
>output to a compiler
You say output as if we "pipe" (Unix term) things to a running process. It's actually just a simple case of saving it to a file and calling the caller with the argument as an argument, the compiler will then (usually) either ran the program or make the binary files that can be executed. For big programs the process of compiling can be rather involved so there's a program just to compile stuff called "make", it allows you to create a script to compile your program more easily (very important for any reasonably sized project).

> what screen fonts/size do you guys like to use for programming?


Most just use the default that their editor gives them, but the "standard" is 80x24 characters. This comes from the old tty days and is more and more irrelevant (i.e. the Linux kernel recommend that you don't exceed 80 characters in a line in the code you're commiting to the project but it's not a big deal if you do).

Also, how many characters you should indent your code is one of the hottest religious wars in programming and it's mostly about screen space and readability.

  No.20884

>>20881
I use interactive languages. I use Emacs controlling a language implementation, which means I type in a valid input and send it to be displayed in the buffer. I collect program fragments into files so they can be more easily loaded if I want.

I do use APL, which Emacs has a special font and input method for.

>what screen fonts/size do you guys like to use for programming?

I use a monospace font and adjust the size so I can easily read the text while keeping as much text on one visual line as possible.
>Can/do you adjust the line spacing and letter spacing for nice sweet screen display?
No.
>Do you have one preferred screen font that works well on Mac Win Linux for cross platform work?
No.

  No.20886

Here's the deal: a text editor does exactly that: it edits raw text files. These files are just one number after another, each representing a character ('a', 'Z', space, etc.). There's no formatting information or anything in the file; it's just one character after another.

Things like fonts, colors, etc. are all metadata - that is, they're extra information about text. Text with metadata is called "rich text." Word processors edit rich text.

If you're writing a document that you want to look nice for people, you use rich text. If you're writing code or data for use by the computer, you use raw text.

When you're working with raw text, you use your own personal settings for fonts and colors. They're set in your editor, not saved in the file. The editor may use different fonts and colors in the text as an aid to the user (say, functions might be green, variables might be red, etc.), but if I send you the file it'll look completely different to you. The content will be the same, though.

  No.20888

>>20819
If GNU documentation is terrible, I haven't noticed. I think most people are surprised there is documentation.

  No.20889

>>20872
I find that hard to believe. Emacs Lisp is extremely similar to Common Lisp.

  No.20890

>>20888

I never noticed either, until I realized that half the time I needed to know something about Emacs the manual was no help. Either stuff was hard to find or what I wanted wasn't there. So it's either off to Google or delving into elisp source, depending on the nature of what I'm looking up.

Maybe that's just me, though. I oftentimes end up looking up weird stuff. I must say I have better luck with the elisp manual than the Emacs manual.

  No.20892

>>20889
Oh really?

(let ((foo 'bar))
(labels ((qux () foo)
(quux () (let ((foo 'baz)) (qux))))
(quux)))

CL => BAR
ELisp => BAZ

  No.20893

>>20881
>what screen fonts

Terminus, or whatever's on my system at the time

>size do you guys like to use for programming?


My monitor size. But I try to keep it readable for the 80x24 people.

>Can/do you adjust the line spacing and letter spacing for nice sweet screen display?


No. That's a really bad idea when you're programming: most programs are designed to be viewed with a monospace font, and you'll throw off the alignment if you mess with variable width stuff. Especially if you're writing LISP.

>Do you have one preferred screen font that works well on Mac Win Linux for cross platform work?


No. I'll use whatever's available. Have SSH, will travel.

  No.20895

>>20889
Only superficially IMO, in that it also uses 'defun' and it has a separate function namespace

  No.20899

>>20870
LibreOffice includes a word processor, not strictly a text editor. Text editors are programs like gedit, nano, notepad, kate, et cetera. The text fields in a web browsers, such as the one where you type posts in this very site, are also technically a type of text editor.

Word processors like LibreOffice Writer are used to create and edit documents. In addition to text data, the files contain information such as fonts, typesetting, layout, images, formatting, and other details about the contents relevant to seeing a document on screen or printed.

Text editors edit what's called "plain text". When you open a file in a text editor, the only contents from that file are the characters on your screen. The fonts, colors, etc. are included by the editor itself.

Computer programs are almost invariably written in plain text programming code. Your image is an example of what typical program code looks like, though the contents are humorous fake code. Again, the color, font, margin size, etc. do not matter for the program's function, nor are they included in the text file with the code. They are added by the editor.

Different text editors offer different features, such as syntax coloring, which means automatically adding colors to different parts of the code to easily see at a glance what different words or phrases in the code are; keyboard shortcuts; folding, which means temporarily hiding blocks of code you're not focusing on; plugins for different programming languages or general usage; and much more. Many such features are extremely useful for programmers and prose writers alike, so they are an important topic for programmers and some other writers. It is not, however, universally agreed which text editor offers (or in some cases lacks) the right features.

  No.20900

>>20881
>what screen fonts/size do you guys like to use for programming?
I usually have either Anonymous Pro or Source Code Pro (11 point) set on my terminals which I use for other tasks than just programming. Since my editor runs in the terminal, that's what I use for programming as well.
Can/do you adjust the line spacing and letter spacing for nice sweet screen display?
Technically yes, but monospaced fonts are the norm for programming for various reasons. Blank lines are sufficient for vertical whitespace control in programming. Readability issues and formatting are commonly debated, but the issues discussed are usually slightly different than they are in conventional typography.
Do you have one preferred screen font that works well on Mac Win Linux for cross platform work?
Anonymous Pro/Source Code Pro like I said above. Standard font formats work on all major platforms so that is not a big concern. I don't run Windows or OS X on my machines, though, so if I'm temporarily working on one of those, I will just use some system default font. Courier is good enough, even if it's not the loveliest monospace around.

  No.20903

>>20892
C-h v lexical-binding

>>20895
If you look at code written in it, it looks like Common Lisp. Despite lacking CLOS, an advanced exception system, or namespaces, most of the bodies of functions in Emacs Lisp without editor functions could be easily converted to Common Lisp.
http://orgmode.org/cgit.cgi/org-mode.git/tree/lisp/ob-core.el?id=release_9.0.2

  No.20909

>>20903
As they already showed you, Elisp has dynamic binding, which is quite a big difference to me, especially since CL'ers rely so much on closures.
Also, you said it yourself: no namespaces, hence, no gensym (as far as I know).
Those two alone make a big difference, especially the first

  No.20911

>>20909
>(as far as I know)
You can look it up. You'll get all the answers you want and then we can talk about how things are instead of how they might be.
C-h v lexical-binding
C-h f gensym
Emacs has supported lexical binding for a long time. Gensym does exist.

(defmacro switch (a b)
(let ((temp-sym (gensym)))
`(progn
(setf ,temp-sym ,a)
(setf ,a ,b)
(setf ,b ,temp-sym))))

(let ((a 3)
(b 5))
(switch a b)
(message "a: %d, b: %d" a b))

(macroexpand
'(switch a b))

  No.20913

>>20911
Emacs ostensibly supports Lexical Binding, but it's uncommonly used, relatively speaking: Most of the elisp code you'll see in the wild is using dynamic binding, and sometimes macros to simulate lexical scope.

It does have gensym, though. Just no namespaces. I don't know why >>20909 thought one required the other.

  No.20914

>>20911
>>20913
Apologies, I should research more. I just remember I was told that emacs used dynamic binding by default.
About gensym, it says in Land of Lambda that gensym creates a symbol in an empty namespace, so I figured that's how you make new symbols. On the other hand I can see it would be easy to just create a nameless symbol

  No.20915

>>20914
There are a variety of approaches to implementing gensym. CL might use namespaces (I don't know), but another common approach is the use of "uninterned symbols": which are sort of the symbols without a name that you describe.

More precisely, they're symbols which, upon instantiation, are guaranteed to be freshly allocated, regardless of name, and aren't put in the symbol table. That way, only code which holds an *explicit reference* to the symbol (the code that called gensym) can access it and its value.

  No.20916

>>20911
Look into psetf and psetq.

>>20914
>>20915
Yes. Emacs implements gensym similarly to most Common Lisp implementations.

Here's the Emacs and SBCL implementations, for reference:
(defun cl-gensym (&optional prefix)
"Generate a new uninterned symbol.
The name is made by appending a number to PREFIX, default \"G\"."
(let ((pfix (if (stringp prefix) prefix "G"))
(num (if (integerp prefix) prefix
(prog1 cl--gensym-counter
(setq cl--gensym-counter (1+ cl--gensym-counter))))))
(make-symbol (format "%s%d" pfix num))))

(defun gensym (&optional (thing "G"))
#!+sb-doc
"Creates a new uninterned symbol whose name is a prefix string (defaults
to \"G\"), followed by a decimal number. Thing, when supplied, will
alter the prefix if it is a string, or be used for the decimal number
if it is a number, of this symbol. The default value of the number is
the current value of *gensym-counter* which is incremented each time
it is used."
(multiple-value-bind (prefix int)
(if (integerp thing)
(values "G" thing)
(values thing (let ((old *gensym-counter*))
(setq *gensym-counter* (1+ old))
old)))
(make-symbol (%make-symbol-name prefix int))))
In both cases, make-symbol is used; this primitive simply creates a symbol, without performing other bookkeeping, such as interning it. It's that simple.

Common Lisp also provides dynamic scope, a variable of which it denotes special.

  No.20924

>>20916
...But that's cl-gensym. How does regular emacs gensym work? is it different?

  No.20929

File: 1482177973725.png (211.6 KB, 124x200, 1478040400895.png)

>>20924
gensym is an alias for `cl-gensym' in `cl.el'.

(gensym &optional PREFIX)

Generate a new uninterned symbol.
The name is made by appending a number to PREFIX, default "G".

[back]

  No.20930

THE CULT OF VIM

pic related

  No.20931

File: 1482178730529.png (20.16 KB, 182x200, 2016-12-19-151719_5280x1080_scrot.png)

>>20930
thanx for uploading :P

  No.20938

>>20930
Vim is an abomination: Just look at VimL.

There are only two True Editors. Vi, and Emacs. Vim is a false good, placed to tempt you off the path of salvation by ED. ED IS THE STANDARD TEXT EDITOR.

  No.20940

>>20938

sed 's/a false goo/go/'

  No.20945

>>20938
This, I need an EDITOR, not a VIITOR, not an EMACSITOR.
>>20940
lol he doesn't even know how to use regular expressions. You sure you use ed at all?

  No.20946


  No.20951

>>20945
It started with me griping about the awfulness of vim, but once I called it a false god, there was only one place to go from there.

>>20946

The regex looked alright to me. If you're asking about the other part of the comment, look no further than https://www.gnu.org/fun/jokes/ed-msg.html, the GNU Project's archive of the famous `ed man! !man ed` rant which both posts drew upon

  No.20956

>>20951
>Vim is a false good
s/a false goo/go/
>Vim is god

Perhaps you meant
s/false goo/false go/
or just
s/goo/go/

  No.20961

>>20956
Oh. I didn't realize I'd made that mistake. I thought the post was intended to be s/a false go/g/, which is a totally valid substitution for somebody who entirely disagrees with the premise.

D'oh.

  No.20968

>>20951
Also, >>20946 is clearly an ed(1) joke.

  No.20970

>>20968
It's awkward when you realize that you had no idea what was going on in the thread for 24 hours, despite participating...

  No.20985

can you underage hipsters just use real IDEs like the rest of us

thanks