61–70 of 175 posts
Earlier quoted context omitted.
I see this occasionally. Why can't you edit locally?
Sometimes it’s policy (no source code on laptops), but mostly it’s because my line of work uses the verilog language and the tool suites require “very stable” (read: archaic) versions of Linux.
Earlier quoted context omitted.
The upside for anything like this is that the barrier to entry being higher, the people who do this tend to create higher quality things overall and maybe even share them. It's not my idea, it's the premise from http://winestockwebdesign.com/Essays/Lisp_Curse.html
Have you looked at the VS Code marketplace? It is not great. The LSP modes are great and then here and there you get interesting extensions, but a bunch of it I would not call higher quality by any means. (I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)
The extensions I've generally used were quite solid, haven't had many problems with them.
The net result for common iteration ops is quite nice, and has options for reasonable optimizations in the world of lisp where macros are real.
Earlier quoted context omitted.
The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs th…
> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs. Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs. Emacs…
VSCode has much better integration with the languages and toolchains that people are actually using in 2018 -- Node, Go, Rust. The point goes to VSCode.
VSCode has a modern UI that looks and works like the other applications people use every day. The point goes to VSCode.
With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too. So that one's a tie, I guess. Nobody except retrocomputing enthusiasts cares about terminals anymore; when kids today hear "terminal" they think of gnome-terminal (and some of them agitate to have it replaced with something that can present a richer experience than ANSI/VT100 can).
The sun has largely set on Emacs's relevance. Objectively better tools have come along.
Earlier quoted context omitted.
For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom. One major reason for me to use Emacs and not newer software is that it i…
Both Atom and VSCode are multiplatform and can run on any platform emacs can. Hell there's a version of it that runs in-browser. Both have commercial backing and the platform is built ok Chrome. Hard to imagine a world where any of that adds up to ephemeral.
Here's what grinds my gears: That the cursor follows the visible buffer. It would be nice to be able to scroll to another part of a file and then just start typing and be back where I was ... I mean I could understand if this was an efficiency thing to do with scaling to large files due to a kind of a tiling memory model or something, but emacs doesn't even do that! It's not a huge deal I've learned to get used to us…
The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs th…
Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things.
Earlier quoted context omitted.
The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs th…
>>For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs) Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, n…
Weird place to vent. But I find it so interesting that Emacs in all it's wisdom does not have (to me) acceptable undo behavior. Sometimes when I want to undo a bit, it undoes so much that I have to do a few seconds of copy-pasting.
My gripe is that I only just discovered the other day it chokes on large files, and even the vlfi (very large files) extension is quite cumbersome. I was quite dismayed to tell you the truth!
E.g. SQL dumps and such.
Earlier quoted context omitted.
> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs. Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs. Emacs…
JavaScript is ubiquitous and acceptable for most of the same purposes as Lisp. It has a much bigger developer ecosystem. The point goes to VSCode. VSCode has much better integration with the languages and toolchains that people are actually using in 2018 -- Node, Go, Rust. The point goes to VSCode. VSCode has a modern UI that looks and works like the other applications people use every day. The point goes to VSCode.…
The last time I checked on this very forum, Lisp people don't even consider scheme as a lisp. Only CL and Elisp came into their category of Lisp.
>>modern UI that looks and works like the other applications people use every day
The point about vi and emacs is not have that UI for the exact opposite reasons you state. Developer tools are not every day things like scissors or door handles. These are more like specialized tools, designed for one special purpose(Text editing).
Also this whole idea of putting beginner friendliness ahead of all design goals leads to tools that are very easy for beginners to work with but do nothing more than that.
The whole point about programming is to automate complex non trivial tasks.
>>Nobody except retrocomputing enthusiasts cares about terminals anymore
Wow! Just wow! Curious to know what you work on daily.
I thought even in this era front end programmers had a fair bit of exposure to the command line.
But if you are telling me only 'retrocomputing enthusiasts' care about the terminal, I have to wonder where these sort of programmers come from.
>>With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too.
Actually no. But based on your thoughts about the terminal, I can see why you wrote that.
>>The sun has largely set on Emacs's relevance.
Emacs will never have the user share of something like Eclipse. But then eclipse won't have the life of Emacs either. These are tools aimed at different category of people.
Here's what grinds my gears: That the cursor follows the visible buffer. It would be nice to be able to scroll to another part of a file and then just start typing and be back where I was ... I mean I could understand if this was an efficiency thing to do with scaling to large files due to a kind of a tiling memory model or something, but emacs doesn't even do that! It's not a huge deal I've learned to get used to us…
The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs th…
Moreover, you did not mention any of the things that make Emacs great. Its mode-based buffer-centric architecture comes from the Lisp Machines, maps well to countless disparate tasks and has certainly stood the test of time. Emacs is essentially the closest thing we have to a Lisp Machine.
Atom and VS Code on the other hand are ad-hoc editors on top of environments that can only be said to re-implement old, dead-end ideas and do so badly.
I'm not sure why you mentioned Gosling, if not to mislead, since he's never as far as I know been a Lisper (Mocklisp is a mockery of Lisp) and his contributions to GNU Emacs -- besides inspiring Stallman to come up with something better -- were minimal and very quickly rewritten or removed. Gosling's influence to the architecture (Lisp Machines, Symbolics) and evolution of GNU Emacs has been NIL.