My perspective as a mid-level user on pros/cons of different editors

My perspective as a mid-level user on pros/cons of different editors

[Rudi C]

[-- Attachment #1: Type: text/plain, Size: 8513 bytes --]

# Jetbrains IDEs

Heavyweight, hardest to customize, usually the most feature-rich and
performant. I like them best for static, compiled languages such as rust
and scala, as they are the most powerful and robust there. My experience
with Pycharm has been lousy (The IDE suddenly said everything was
undefined. I switched back to my emacs after wasting some time
troubleshooting the problem.). Good support for frameworks and inline,
inner languages such as HQL (a SQL variant for ORM in Java). The
documentation panel doesn’t wrap correctly in many languages. No remote
editing support.

Adding support for a new language is usually as easy as searching for a
plugin and installing that. Things work out of the box. Well.

Can’t run in the terminal. Closed source, though plugins tend to be open
source.

# vim/neovim with little config and plugins

Extremely lightweight. Great remote editing with scp. I also use vim
emulation everywhere else, so I obviously like that. Vim modal editing and
minimalism lends itself well to use on remote terminals directly,
especially on iOS. The lack of configuration also means it never breaks, or
needs to wait to index, or whatever. It’s also either preinstalled or easy
and quick to install on unix machines.

Obviously, little support for any IDE feature.

## Spacevim

Somewhat slow-ish. The configuration is also specific to Spacevim, and so
locks the user in, and makes following documentation elsewhere online
difficult. The Spacemacs-inspired keybindings are a delight, and so are
some miscellaneous features Spacevim enable by default. Needs patched fonts
to display correctly, but doesn’t install them for you automatically. I
personally have an alias that invokes neovim with Spacevim, but I keep the
default config of my vims minimal. Spacevim also is somewhat buggy, and
their support community is weak.

Spacevim has modules for different languages, which in my not so informed
opinion are not all that good. Seemed out-of-datem and unmaintained to me.
This, though, is a problem all modular starter packs (Spacemacs, Doom
Emacs, Spacevim) except VSCode share, more or less, with Spacemacs’ being
the best IMO.

# Plain Emacs

I have never tried plain, unconfigured emacs except for reporting bugs. My
first impression of its UI is bad. I think hiding the toolbar improves the
UI.

## Spacemacs

Not well maintained. PRs can be very slow to merge. Master branch is
basically dead. Issues also don’t seem too well; The good ones include a
workaround in the comments but no fix in the repo, and the bad ones are
marked “stale” by a bot with little progress. Still, the community is
pretty helpful and the workarounds, ahm, actually work, so not that bad.
Has lots of (LOTS OF) features and cruft, which can occasionally make
Spacemacs buggy and slow. Tramp never worked for me in Spacemacs, for
example. Spacemacs famous keybinding scheme rocks, and is the best one I
have seen in any software. The configuration (at least the version I
started with, perhaps it has changed) mixed private Spacemacs config with
user elisp code and emacs customization, which is a bad practice. Spacemacs
supports a modular pack system, and names them “layers.” These layers are
unmaintained and unoptimal in my experience/opinion, but they nonetheless
provide the best JustWorks experience in the emacs/vim world.

Spacemacs can become quite heavy and slow to start (perhaps I have too many
layers active). Daemon mode recommended.

## Doom Emacs

Friendly maintainer and good community in discord. Provides a snappy UI and
good defaults. Enables lots of good features by default, but few bad ones.
Does not feel crufty. Fast to start. Somewhat lightweight. Supports modules
for adding functionality like language support, but again the modules are
not that good. I think they are worse than Spacemacs, but better than
Spacevim; Idk. Still has a few bugs and rough edges (for example, you need
to disable solaire-mode for the daemon mode working correctly), but much
much better than Spacevim and Spacemacs. Copies Spacemacs keybinding
scheme, better than Spacemacs itself IMO.

The configuration system is the best one I have seen in any editors.
Provides good macros for helping one customize things. I imagine copying
the relevant code should be easy, so minimal lock-in, hopefully.

## Emacs in general

The most extensible software I have ever seen. The easiest to extend
between the editors. Horrible support for most languages; One needs to
spend a lot of time to configure support for a new language, and things
keep breaking when anything updates or even randomly. Most languages won’t
ever get good support even after substantial time invested in configuring
them. Adding IDE features tends to make Emacs slow. My best experience has
been with elisp, clojure and coq. My worst experience has been (probably?
Most of my experience in language support has been terrible anyways) scala
via (now defunct) ENSIME. Just today, I tried getting julia to work via
lsp. After spending an hour or two, I understood that this simply was nigh
impossible with Julia 1.4.
In summary, Emacs is good for some specific well-supported languages (even
then with lots of harassment and breakages), and obscure languages that are
not supported well anywhere (e.g., verilog), and non-code text editing.
It’s also an engine one can build one’s own software on, though I think it
might be that using other tools (perl, fzf, ripgrep, ...) might be easier
at least in the short term.
Emacs is also used for things like Twitter and Reddit. I found these uses
badly supported, and not pragmatic. They appealed to my inner nerd, but I
think a dedicated CLI will be better, and the original website possibly the
best.

tramp mode supports remote editing.

Best experience in REPL-orinted programming between all the editors. Emacs
itself is one huge REPL.

Free software.

# VSCode

Everything (almost always) just work. Supports lots of languages, and
supports them well. Adding support is easy as easy as searching for the
language and clicking install. Customizing predefined options is a breeze
with both good GUI support and good JSON support. Extending stuff without
writing a verbose plugin is pretty much impossible. Even plugins are only
offered a limited API for extending VSCode.

Can’t run in the terminal.

Good remote editing support. Beautiful UI. Inefficient because JS. Very
well maintained, and regularly GROWS BETTER. Next year this time it will
probably be THE notebook editor. Professional culture in maintenance also
means the needs of experts are deprioritized. Does not support a
documentation panel, though a documentation popup is supported. While
language support is top notch, other good features are not as mature as
emacs/vim.

The most innovative of the editors listed here.

# Conclusion

With VSCode around, emacs is simply not worth the investment for new users
IMO. I think most of the automation value should be realizable by using a
combination of VSCode extensions, unix scripts, interactive CLI apps, and
GUI scripting tools. To make emacs viable again:

- Complete, first-class LSP support. Without this, all the fancy features
of emacs are basically useless. Remember, a car needs first and foremost to
move people from A to B. A stationary car with a rocket launcher is cool
but also not much of a car.
- Maintained module systems a la Spacemacs and Doom. Extensibility is
great, but this is no excuse to have no defaults or bad defaults. As the
market is asserting, most of the value can be achieved via generic
defaults. All of that extensibility is less than 10-20 percents of the
value of a good, capable IDE.
    - Note that the above should make breakages less likely, as modules pin
their packages to specific commits/versions.

Of course, it takes more than making emacs viable to make it popular, but
as things stand, emacs is not worth learning even for someone who wants to
become a power user. It’s of course still worth it for those of us already
invested in the platform (I personally use Doom Emacs plus my own config as
my main editor), but NOT for new users. I fear that the situation will only
get worse in the future, as VSCode enjoys both being a popular opensource
project in the popular JavaScript language, and a pet project of Microsoft.

[-- Attachment #2: Type: text/html, Size: 9894 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

Hi Rudi,

Thanks for the write-up.

Just a few brief comments.

On 20.05.2020 03:29, Rudi C wrote:
> # Plain Emacs
> 
> I have never tried plain, unconfigured emacs except for reporting bugs. 
> My first impression of its UI is bad. I think hiding the toolbar 
> improves the UI.

The toolbar's look depends on the OS and the DE. They look reasonable 
under GNOME, for instance.

> In summary, Emacs is good for some specific well-supported languages 
> (even then with lots of harassment and breakages), and obscure languages 
> that are not supported well anywhere (e.g., verilog)

verilog-mode is developed externally and has an issue tracker here: 
https://github.com/veripool/verilog-mode/issues

You might have more luck if you report whatever problems you're having.

> - Complete, first-class LSP support. Without this, all the fancy 
> features of emacs are basically useless. Remember, a car needs first and 
> foremost to move people from A to B. A stationary car with a rocket 
> launcher is cool but also not much of a car.

Have you tried Eglot?

Re: My perspective as a mid-level user on pros/cons of different editors

[Rudi C]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

I was happy with the verilog-mode! It was great! I mean it didn't have many
IDE features (just syntax highlighting?) but that was all I needed. I am
saying emacs is good for this stuff! :D
I have not tried eglot. I imagined it would not be different from the lsp
clients set up by Spacemacs and Doom. (My experience with Spacemacs' lsp
support was nightmarish. The nonfunctional, intrusive, slow lsp kept
activating itself even when disabled. I had to exclude all lsp packages and
even then sometimes lsp showed up. :| ) I'm trying eglot out now. :-) But
even if it is good, I think it's important that such core functionality be
given first-class support. Neovim has also adopted this approach, and is
rolling its own builtin lsp client despite already having a few clients.

On Wed, May 20, 2020 at 6:06 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Hi Rudi,
>
> Thanks for the write-up.
>
> Just a few brief comments.
>
> On 20.05.2020 03:29, Rudi C wrote:
> > # Plain Emacs
> >
> > I have never tried plain, unconfigured emacs except for reporting bugs.
> > My first impression of its UI is bad. I think hiding the toolbar
> > improves the UI.
>
> The toolbar's look depends on the OS and the DE. They look reasonable
> under GNOME, for instance.
>
> > In summary, Emacs is good for some specific well-supported languages
> > (even then with lots of harassment and breakages), and obscure languages
> > that are not supported well anywhere (e.g., verilog)
>
> verilog-mode is developed externally and has an issue tracker here:
> https://github.com/veripool/verilog-mode/issues
>
> You might have more luck if you report whatever problems you're having.
>
> > - Complete, first-class LSP support. Without this, all the fancy
> > features of emacs are basically useless. Remember, a car needs first and
> > foremost to move people from A to B. A stationary car with a rocket
> > launcher is cool but also not much of a car.
>
> Have you tried Eglot?
>

[-- Attachment #2: Type: text/html, Size: 2505 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 12:35 PM Rudi C <rudiwillalwaysloveyou@gmail.com> wrote:
>
> I was happy with the verilog-mode! It was great! I mean it didn't have many IDE features (just syntax highlighting?) but that was all I needed. I am saying emacs is good for this stuff! :D
> I have not tried eglot. I imagined it would not be different from the lsp clients set up by Spacemacs and Doom. (My experience with Spacemacs' lsp support was nightmarish. The nonfunctional, intrusive, slow lsp kept activating itself even when disabled. I had to exclude all lsp packages and even then sometimes lsp showed up. :| ) I'm trying eglot out now. :-) But even if it is good, I think it's important that such core functionality be given first-class support. Neovim has also adopted this approach, and is rolling its own builtin lsp client despite already having a few clients.

Hi Rudi, your write-up is very interesting, and your ideas about
LSP seem to converge with mine, more or less.  Indeed, maybe
Eglot shouldn't exist at all, it should just be built-in Emacs
functionality.  But that's for later.  For now, l'm interested in your
feedback on Eglot, either here or in its Github tracker.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 15:18, João Távora wrote:
> But even if it is good, I think it's important that such core functionality be given first-class support.

What does that mean?

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 1:57 PM Dmitry Gutov <dgutov@yandex.ru> wrote:>
> On 20.05.2020 15:18, João Távora wrote:
> > But even if it is good, I think it's important that such core functionality be given first-class support.
>
> What does that mean?

I didn't write this, Rudi did. I personally don't read too much into it.
But, I suppose it means it shouldn't be an afterthought, as it seems
now, an appendix.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 16:01, João Távora wrote:
> But, I suppose it means it shouldn't be an afterthought, as it seems
> now, an appendix.

Is it?

But there are different ways to address it, clearly.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 2:05 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20.05.2020 16:01, João Távora wrote:
> > But, I suppose it means it shouldn't be an afterthought, as it seems
> > now, an appendix.
>
> Is it?

I can't answer for Rudi, but it does IMO.  Having to say "yes
I want to use LSP" in some way either via something called
"lsp-mode" or by using a peculiarly named package, is very
much appendix-like.   A non-appendix view would be: "I want to
work on my Python, C++, Go program" and go do that, not
caring about what was going on underneath at all, LSP, treesitter,
CC-mode if-then-elses, you name it.

João



-- 
João Távora

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 16:10, João Távora wrote:
> A non-appendix view would be: "I want to
> work on my Python, C++, Go program" and go do that, not
> caring about what was going on underneath at all, LSP, treesitter,
> CC-mode if-then-elses, you name it.

We won't be able to do this.

IIRC the preceding discussion, we won't be allowed to even install 
language servers automatically.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 2:14 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 20.05.2020 16:10, João Távora wrote:
> > A non-appendix view would be: "I want to
> > work on my Python, C++, Go program" and go do that, not
> > caring about what was going on underneath at all, LSP, treesitter,
> > CC-mode if-then-elses, you name it.
> We won't be able to do this.

Don't be such a Cassandra: have you seen the future?
We'll try to come as close as possible.

Anyway, it is precisely in this sense that I try that Eglot
provide the least amount of interactive commands and
user options, and no keybindings at all.  So that people
"see it" as little as possible of it.  They just see xref, project,
flymake diagnostics, eldoc, etc. This is quite different
from lsp-mode (at least the last time I looked at it).  Of
course if major modes were in on the play, we could
reduce the visibility of Eglot even more, maybe just
reduce it to `eglot-connect` and `eglot-disconnect`, maybe
call them `start-ide-ing` and `stop-ide-ing` for abstraction.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 16:32, João Távora wrote:
> Anyway, it is precisely in this sense that I try that Eglot
> provide the least amount of interactive commands and
> user options, and no keybindings at all.  So that people
> "see it" as little as possible of it.

The lack of a binging to show the doc (last time I tried) kind of hurts.

> They just see xref, project,
> flymake diagnostics, eldoc, etc. This is quite different
> from lsp-mode (at least the last time I looked at it).

IIUC, LSP also provides extra actions that tie into refactoring, 
reorganizing imports, etc. How does Eglot deal with it?

> Of
> course if major modes were in on the play, we could
> reduce the visibility of Eglot even more, maybe just
> reduce it to `eglot-connect` and `eglot-disconnect`, maybe
> call them `start-ide-ing` and `stop-ide-ing` for abstraction.

That sounds pointless. It's not like the users will look for 'M-x 
start-ide-ing' command specifically.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 2:59 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20.05.2020 16:32, João Távora wrote:
> > Anyway, it is precisely in this sense that I try that Eglot
> > provide the least amount of interactive commands and
> > user options, and no keybindings at all.  So that people
> > "see it" as little as possible of it.
>
> The lack of a binging to show the doc (last time I tried) kind of hurts.

There is  C-h ., which you yourself suggested once.  But interesting
that you bring that up.  I did put one now, precisely because it kind
of hurts, and because C-h . should be handled by eldoc.el or
whereabouts.

And that is why I made eldoc.el a :core package ;-)

Anyway, see https://github.com/joaotavora/eglot/issues/454

> > They just see xref, project,
> > flymake diagnostics, eldoc, etc. This is quite different
> > from lsp-mode (at least the last time I looked at it).
>
> IIUC, LSP also provides extra actions that tie into refactoring,
> reorganizing imports, etc. How does Eglot deal with it?

In LSP, they are associated with the diagnostic object.  So
they go into flymake's facility of interactive diagnostics.  But
part of it is currently in Eglot, as commands.  The long-term
goal is for it not to be, as I stated.

> > reduce it to `eglot-connect` and `eglot-disconnect`, maybe
> > call them `start-ide-ing` and `stop-ide-ing` for abstraction.
>
> That sounds pointless. It's not like the users will look for 'M-x
> start-ide-ing' command specifically.

Why? Just tell them at the splash screen: "to start advanced
IDE features, M-x start-ide-ing".  Weren't you the one talking
about a "how to IDE" tutorial?  Or was it someone else.  It
sould be a 1-step tutorial in this case.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 17:06, João Távora wrote:

>> The lack of a binging to show the doc (last time I tried) kind of hurts.
> 
> There is  C-h ., which you yourself suggested once.  But interesting
> that you bring that up.  I did put one now, precisely because it kind
> of hurts, and because C-h . should be handled by eldoc.el or
> whereabouts.

'C-h .' shows documentation for a function? Or diagnostics/errors?

>> IIUC, LSP also provides extra actions that tie into refactoring,
>> reorganizing imports, etc. How does Eglot deal with it?
> 
> In LSP, they are associated with the diagnostic object.  So
> they go into flymake's facility of interactive diagnostics.  But
> part of it is currently in Eglot, as commands.  The long-term
> goal is for it not to be, as I stated.

No diagnostics will ask you to refactor a method. To do a 
rename/extract/override kind of action.

That's simply a missing feature, I guess.

>>> reduce it to `eglot-connect` and `eglot-disconnect`, maybe
>>> call them `start-ide-ing` and `stop-ide-ing` for abstraction.
>>
>> That sounds pointless. It's not like the users will look for 'M-x
>> start-ide-ing' command specifically.
> 
> Why? Just tell them at the splash screen: "to start advanced
> IDE features, M-x start-ide-ing".  Weren't you the one talking
> about a "how to IDE" tutorial?  Or was it someone else.  It
> sould be a 1-step tutorial in this case.

Um, okay. If there is a splash screen, couldn't it say 'M-x 
eglot-start'? Or do you dislike that name now, for some reason?

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 3:13 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 20.05.2020 17:06, João Távora wrote:

> 'C-h .' shows documentation for a function? Or diagnostics/errors?

Maybe both. This is still under discussion.  Let's have your feedback
there in the issueI linked to.

> No diagnostics will ask you to refactor a method. To do a
> rename/extract/override kind of action.
>
> That's simply a missing feature, I guess.

No not entirely, I think. There's eglot-rename.  Yes another command.
But the extract/override stuff is probably "code actions".  I'm not
100% sure how they work right now, I can check later.

But anyway, they could be supported by Flymake diagnostics. Or
some other abstraction for supporting "interesting regions".

> Um, okay. If there is a splash screen, couldn't it say 'M-x
> eglot-start'? Or do you dislike that name now, for some reason?

I don't _dislike_ the name.  I chose a unique name because I felt
"lsp" would be too intrusive on a technology (obviously, someone
else thought otherwise...).

It could, but "Eglot", as Stefan pointed out, sounds unnecessarily
peculiar and foreign.  You install Emacs to play around and the
one of the first things you read is about this thing called "Eglot".
Needless friction.  It could be an alias, though.

Anyway, all this is putting the cart way ahead of the horse.
it's nice to have a broad roadmap, but not too much.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 17:31, João Távora wrote:
> On Wed, May 20, 2020 at 3:13 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>> On 20.05.2020 17:06, João Távora wrote:
> 
>> 'C-h .' shows documentation for a function? Or diagnostics/errors?
> 
> Maybe both. This is still under discussion.  Let's have your feedback
> there in the issueI linked to.

Okay. Continuing with the discussion on GitHub, then.

>> No diagnostics will ask you to refactor a method. To do a
>> rename/extract/override kind of action.
>>
>> That's simply a missing feature, I guess.
> 
> No not entirely, I think. There's eglot-rename.  Yes another command.
> But the extract/override stuff is probably "code actions".  I'm not
> 100% sure how they work right now, I can check later.

Sounds good.

> But anyway, they could be supported by Flymake diagnostics. Or
> some other abstraction for supporting "interesting regions".

Not sure all "code actions" have some pre-defined regions.

>> Um, okay. If there is a splash screen, couldn't it say 'M-x
>> eglot-start'? Or do you dislike that name now, for some reason?
> 
> I don't _dislike_ the name.  I chose a unique name because I felt
> "lsp" would be too intrusive on a technology (obviously, someone
> else thought otherwise...).
> 
> It could, but "Eglot", as Stefan pointed out, sounds unnecessarily
> peculiar and foreign.

*shrug* I like it.

> Anyway, all this is putting the cart way ahead of the horse.

Indeed.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> But anyway, they could be supported by Flymake diagnostics. Or
>> some other abstraction for supporting "interesting regions".
>
> Not sure all "code actions" have some pre-defined regions.

It's complicated.  You request them for a region, but you also give them
"context", which _are_ the diagnostics.  Then you get back a big list of
code-actions that apply to that region, and normally they come back with
specific pointers back to the diagnostics they "resolve". 

>> It could, but "Eglot", as Stefan pointed out, sounds unnecessarily
>> peculiar and foreign.
> *shrug* I like it.

I mean, I like it too, that's why I came up with it :-)  It's certainly
googleable.  But you asked about Rudi's assertion of "first class
support".  For me, first class means to having a quirky name for it,
it's just there.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 19:22, João Távora wrote:
> For me, first class means to having a quirky name for it,
> it's just there.

A quirky name like xref, eww, winner, eldoc or flymake?

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 6:23 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20.05.2020 19:22, João Távora wrote:
> > For me, first class means to having a quirky name for it,
> > it's just there.
>
> A quirky name like xref, eww, winner, eldoc or flymake?

But a new user never types or needs to learn those, he just finds
a file and all those things are activated.  He may learn the names
later on.

But OK, you're probably right, we do need a prefix/namespace
and it might as well be "eglot". Pragmatically, I'd alias M-x eglot
to ide-start-lsp or something like that. But I won't make a question
of it.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[slang]

> On 20 May 2020 21:14 João Távora <joaotavora@gmail.com> wrote:
> 
>  
> On Wed, May 20, 2020 at 6:23 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> >
> > On 20.05.2020 19:22, João Távora wrote:
> > > For me, first class means to having a quirky name for it,
> > > it's just there.
> >
> > A quirky name like xref, eww, winner, eldoc or flymake?
> 
> But a new user never types or needs to learn those, he just finds
> a file and all those things are activated.  He may learn the names
> later on.
> 
> But OK, you're probably right, we do need a prefix/namespace
> and it might as well be "eglot". Pragmatically, I'd alias M-x eglot
> to ide-start-lsp or something like that. But I won't make a question
> of it.
> 
> João

I've been using emacs a couple of years now (and eglot) and from my experience names do not matter that much - it is more to guide the user where to look and what to use - e.g. for source code navigation lsp, etags, ctags, gtags, dumb-jump (dumb-jump works actually really well in many situations) ... so they have a clear path in front of them. 

Having an lsp client in emacs (whatever the name is) would make it possible to tell users (can even be on a splash screen) -> to IDE type this.

Simon

Re: My perspective as a mid-level user on pros/cons of different editors

[Arthur Miller]

slang@yellowfrog.io writes:

>> On 20 May 2020 21:14 João Távora <joaotavora@gmail.com> wrote:
>> 
>>  
>> On Wed, May 20, 2020 at 6:23 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>> >
>> > On 20.05.2020 19:22, João Távora wrote:
>> > > For me, first class means to having a quirky name for it,
>> > > it's just there.
>> >
>> > A quirky name like xref, eww, winner, eldoc or flymake?
>> 
>> But a new user never types or needs to learn those, he just finds
>> a file and all those things are activated.  He may learn the names
>> later on.
>> 
>> But OK, you're probably right, we do need a prefix/namespace
>> and it might as well be "eglot". Pragmatically, I'd alias M-x eglot
>> to ide-start-lsp or something like that. But I won't make a question
>> of it.
>> 
>> João
>
> I've been using emacs a couple of years now (and eglot) and from my experience
> names do not matter that much - it is more to guide the user where to look and
> what to use - e.g. for source code navigation lsp, etags, ctags, gtags,
> dumb-jump (dumb-jump works actually really well in many situations) ... so they
> have a clear path in front of them.
>
> Having an lsp client in emacs (whatever the name is) would make it possible to tell users (can even be on a splash screen) -> to IDE type this.
>
> Simon
Indeed. As a user, I really want to be able to jump to
declaration/implementation/find references/get completion to work etc. I
wouldn't care as slightest how it is implemented as long as it worked
well. Unfortunately (or fortunately) I know all the minutiae details on
how it works in my copy of Emacs since I had to install each and every
pacakge and configure them all together to get that working for me.
Which indeed took quite some time untill I learned what I need, how to
configure it and finally how to use it.

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> For me, first class means to having a quirky name for it,
>> it's just there.
>
> A quirky name like xref, eww, winner, eldoc or flymake?

IMHO, these are mostly fine.  At least they are somewhat descriptive.

Best regards,
Stefan Kangas

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 21.05.2020 00:21, Stefan Kangas wrote:
> IMHO, these are mostly fine.  At least they are somewhat descriptive.

Eglot = Emacs Polyglot

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 10:26 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 21.05.2020 00:21, Stefan Kangas wrote:
> > IMHO, these are mostly fine.  At least they are somewhat descriptive.
>
> Eglot = Emacs Polyglot

FWIW, Stefan is totally right that this is as far fetched as can be.
It doesn't make much sense, either, Emacs is already pretty
polyglot. But names are names, a rose is a rose, and all that.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Arthur Miller]

João Távora <joaotavora@gmail.com> writes:

> On Wed, May 20, 2020 at 10:26 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 21.05.2020 00:21, Stefan Kangas wrote:
>> > IMHO, these are mostly fine.  At least they are somewhat descriptive.
>>
>> Eglot = Emacs Polyglot
>
> FWIW, Stefan is totally right that this is as far fetched as can be.
> It doesn't make much sense, either, Emacs is already pretty
> polyglot. But names are names, a rose is a rose, and all that.
>
> João
Also "glot" sounds qutie awkward, doesn't it? :-)

RE: My perspective as a mid-level user on pros/cons of different editors

[Drew Adams]

> "glot" sounds qutie awkward, doesn't it? :-)

Perhaps not to a glottis.  It presumably enjoys
producing vocal sounds of all sorts. ;-)

Re: My perspective as a mid-level user on pros/cons of different editors

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

A "glot" is the result of saying  "hmm" or "er" 
to glot out whatever you were previously saying.

;-)

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: My perspective as a mid-level user on pros/cons of different editors

[Drew Adams]

> Eglot = Emacs Polyglot

So the `e' is a wasted char.
Everything in Emacs is Emacs.

https://www.youtube.com/watch?v=f0OJdiHRglc

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Kangas]

João Távora <joaotavora@gmail.com> writes:

> Anyway, it is precisely in this sense that I try that Eglot
> provide the least amount of interactive commands and
> user options, and no keybindings at all.  So that people
> "see it" as little as possible of it.  They just see xref, project,
> flymake diagnostics, eldoc, etc. This is quite different
> from lsp-mode (at least the last time I looked at it).  Of
> course if major modes were in on the play, we could
> reduce the visibility of Eglot even more, maybe just
> reduce it to `eglot-connect` and `eglot-disconnect`, maybe
> call them `start-ide-ing` and `stop-ide-ing` for abstraction.

I like your thinking above.

I agree that, if we want users to interact with it, "eglot" is a pretty
hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
okay here, if that makes sense.

Best regards,
Stefan Kangas

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 17:04, Stefan Kangas wrote:
> I agree that, if we want users to interact with it, "eglot" is a pretty
> hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
> okay here, if that makes sense.

So, what's your opinion on how lsp-mode would react to that particular 
rename, and how should we feel about that?

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 3:07 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20.05.2020 17:04, Stefan Kangas wrote:
> > I agree that, if we want users to interact with it, "eglot" is a pretty
> > hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
> > okay here, if that makes sense.
> So, what's your opinion on how lsp-mode would react to that particular
> rename, and how should we feel about that?

Bahh... From Cassandra to Geraldo...

It's not like "lsp" now _owns_ the name "lsp".

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 17:10, João Távora wrote:

>>> I agree that, if we want users to interact with it, "eglot" is a pretty
>>> hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
>>> okay here, if that makes sense.
>> So, what's your opinion on how lsp-mode would react to that particular
>> rename, and how should we feel about that?
> 
> Bahh... From Cassandra to Geraldo...

 From semi-impolite to rude.

> It's not like "lsp" now _owns_ the name "lsp".

I know your answer to the above questions, of course.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 3:14 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 20.05.2020 17:10, João Távora wrote:
>
> >>> I agree that, if we want users to interact with it, "eglot" is a pretty
> >>> hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
> >>> okay here, if that makes sense.
> >> So, what's your opinion on how lsp-mode would react to that particular
> >> rename, and how should we feel about that?
> >
> > Bahh... From Cassandra to Geraldo...
>  From semi-impolite to rude.

Aww, come on!  It's just that sometimes it seems you
just want to stir up controversy for no benefit.  Can't speak for
Stefan, but sounds he was expressing an idea I agree with:
LSP functionality could have that fact encoded in the name of
the associated command.

But OK we'll call it `M-x
not-that-lsp-the-package-the-other-one-the-protocol-itself-start`

:-)

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 17:37, João Távora wrote:
> Aww, come on!  It's just that sometimes it seems you
> just want to stir up controversy for no benefit.

It was an honest question.

 > Can't speak for
Stefan, but sounds he was expressing an idea I agree with:
LSP functionality could have that fact encoded in the name of
the associated command.

And in another message you expressed an opinion that the user shouldn't 
have to think about any Lumpy Space Princesses, things should just work.

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 20.05.2020 17:37, João Távora wrote:
>> Aww, come on!  It's just that sometimes it seems you
>> just want to stir up controversy for no benefit.
>
> It was an honest question.

Sorry, I didn't read it as such.  And it will inevitably bring back
echoes of a silly feud, for something that is not anywhere near being
really on the table.

> > Stefan, but sounds he was expressing an idea I agree with:
> > LSP functionality could have that fact encoded in the name of
> > the associated command.
> And in another message you expressed an opinion that the user
> shouldn't have to think about any Lumpy Space Princesses, things
> should just work.

Yes, that's even better.  But Stefan's idea is already half-way in the
direction I want to go, hence it is agreeable, because compromise.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[andres.ramirez]

>>>>> "João" == João Távora <joaotavora@gmail.com> writes:


[...]


    João> But OK we'll call it `M-x
    João> not-that-lsp-the-package-the-other-one-the-protocol-itself-start`

proper names improve discoverability.
always you could use alias see some examples:
--8<---------------cut here---------------start------------->8---
(defalias 'cc 'compile)
(defalias 'f 'find-file)
--8<---------------cut here---------------end--------------->8---

Also take in account there is another thread about renaming shr.el. (More
developer time involved).

Best

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 20:57, andres.ramirez wrote:
> Also take in account there is another thread about renaming shr.el. (More
> developer time involved).

Yeah, you can see in that thread what the developer thinks about this idea.

offtopic emacs-and-introspection (was: My perspective as a mid-level user on pros/cons of different editors)

[andrés ramírez]

Hi Dmitry.

>>>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

    Dmitry> On 20.05.2020 20:57, andres.ramirez wrote:
    >> Also take in account there is another thread about renaming
    >> shr.el. (More developer time involved).

    Dmitry> Yeah, you can see in that thread what the developer thinks
    Dmitry> about this idea.
    
Emacs should be introspectable. In the past I have been in the same
position as a developer (not wanting to de a minor change). You know "hot deadlines". Sometimes You want to
"have a break".

But a PR person told me once: You guys (developers). do a lot of
hardwork. But at the end You do not know how to present a good
product (give to few time to product presentation). We (public relations people). Do the contrary. We focus too
much on product presentation (and sometimes the product has not the hardwork you do).

So. When I do not want to do a minor change. I remember that past
conversation. And most of the time I end doing "the minor change".

Best Regards

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 20.05.2020 17:04, Stefan Kangas wrote:
>> I agree that, if we want users to interact with it, "eglot" is a pretty
>> hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
>> okay here, if that makes sense.
>
> So, what's your opinion on how lsp-mode would react to that particular
> rename, and how should we feel about that?

They chose to be uncooperative, AFAIU?  Then where does that leave us?
Maybe the onus is on them to choose a name which will not obviously
conflict with the support we will likely (or obviously) want in core.

It is good that they developed lsp-mode, but it is disappointing that
they have so light-heartedly dismissed the possibility of getting it
into core or GNU ELPA.

If we agree that it is important to have lsp-support in core (my
preference), or at least very easily installible through GNU ELPA, I
don't see why we should worry at all about them somehow owning the
prefix "lsp-".  Because they don't.

On the other hand, we could avoid the problem by using something like
"lsp-core".  It is not optimal but at least helps avoid name clashes.

Best regards,
Stefan Kangas

Re: My perspective as a mid-level user on pros/cons of different editors

[Dmitry Gutov]

On 20.05.2020 18:23, Stefan Kangas wrote:

>> So, what's your opinion on how lsp-mode would react to that particular
>> rename, and how should we feel about that?
> 
> They chose to be uncooperative, AFAIU?  Then where does that leave us?

Did they? These things are not so simple.

lsp-mode is not one person, some of them would likely want to be 
featured in GNU ELPA, but maybe others made it too hard.

And if we split ELPA in two parts, as is being discussed in another 
thread, it should be possible again (in the "extras" part, at least).

> Maybe the onus is on them to choose a name which will not obviously
> conflict with the support we will likely (or obviously) want in core.

I don't see any "obviously" here, but oh well.

> It is good that they developed lsp-mode, but it is disappointing that
> they have so light-heartedly dismissed the possibility of getting it
> into core or GNU ELPA.

Did anybody here actually talk to them about inclusion?

I'm guessing Stefan stopped at the "include s.el" step.

> If we agree that it is important to have lsp-support in core (my
> preference), or at least very easily installible through GNU ELPA, I
> don't see why we should worry at all about them somehow owning the
> prefix "lsp-".  Because they don't.

So we don't care about upsetting even the "friendly" developers among 
lsp-mode team, and either forcing them to rename the package (and thus 
breaking updates for all users who have the package installed), or 
creating general user confusion who would look at the lsp-mode's feature 
list, type 'M-x lsp-connect', and fail to see some of the features?

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 7:19 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> So we don't care about upsetting even the "friendly" developers among
> lsp-mode team, and either forcing them to rename the package (and thus

I, for one, am actually working on a way of getting s.el included
in GNU Elpa with no extra effort from any of its users, which would
include lsp-mode.el I suspect. And the same tool, or proper
namespaces, could be easily used to fix this (IMO quite irrelevant)
"my lsp predates your lsp" question you're  stirring up.

Also, I'm outta this thread,

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> They chose to be uncooperative, AFAIU?  Then where does that leave us?
>
> Did they? These things are not so simple.

I see your point, I'm perhaps not fully informed of all the back and
forths.  Or I don't understand them.

So I'll concede my points and leave this to the best judgement of you
all.  I'm sorry if I stirred up any unnecessary feelings.

Best regards,
Stefan Kangas

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> They chose to be uncooperative, AFAIU?  Then where does that leave us?
>
> Did they? These things are not so simple.

I see your point, I'm perhaps not fully informed of all the back and
forths.  Or I don't understand them.

So I'll concede my points and leave this to the best judgement of you
all.  I'm sorry if I stirred up any unnecessary feelings.

Best regards,
Stefan Kangas

Re: My perspective as a mid-level user on pros/cons of different editors

[João Távora]

On Wed, May 20, 2020 at 3:04 PM Stefan Kangas <stefankangas@gmail.com> wrote:
> > course if major modes were in on the play, we could
> > reduce the visibility of Eglot even more, maybe just
> > reduce it to `eglot-connect` and `eglot-disconnect`, maybe
> > call them `start-ide-ing` and `stop-ide-ing` for abstraction.
>
> I like your thinking above.
>
> I agree that, if we want users to interact with it, "eglot" is a pretty
> hard to understand name.  Perhaps "lsp-start" and "lsp-stop" would be
> okay here, if that makes sense.

It does, to me.  IOW it's better than "eglot".  But let's not tie
ourselves too much into LSP, right?  It's a Open Source
protocol kinda controlled by M$.  We might want to drift to
something better thing in the future.

João

Re: My perspective as a mid-level user on pros/cons of different editors

[Rudi C]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

I think just giving a ready-to-use shell script to people for doing stuff
like installing language servers is good enough, though I agree with Joao
that the more stuff that is automatable be automated the better. I just
tried eglot for Julia via eglot-jl. It didn't work (
https://github.com/non-Jedi/eglot-jl/issues/14), though the bug might be
... Julia's fault. (One of the problems with emacs now is exactly this; As
we lack enough users, the support always lags behind. This might not be
fixable without having a sizable portion of the users.) I just tried
running `eglot` for python (though I'm quite happy with `elpy`, which I
just wasted an hour to get to work with Doom Emacs because of
incompatibilities.), and I got this conflict error `eglot--error: [eglot]
-32602: pkg_resources.VersionConflict: (jedi 0.16.0
(/Users/evar/anaconda/lib/python3.7/site-packages),
Requirement.parse('jedi<0.16,>=0.14.1'))`. I imagine this should be easily
fixable by installing a suitable jedi version, but you get the idea. Here
in emacs things have a way of not working by default, and I personally have
low confidence for investing time in getting things to work. Now jedi is
broken, then another thing might be. (I'm not trying to rip on eglot, it
actually seems the nicest `modular language support` system of emacs that I
have seen, and it is clearly going in the right direction. BUT things don't
work by default.) I have, coincidentally, read through quite a bit of
VSCode's issue on extending support of notebooks to other languages besides
python, and the devs there are obsessive with making things work even when
they are clearly NOT abiding by standards they should be abiding by
(non-standard install locations, non-existent jupyter kernels config, etc).
This is one of the reasons they are having problems supporting new
languages. (Their current system is very python-tangled and seems to use
private APIs of jupyter or sth.)
As I pointed to earlier, `elpy` was incompatible with Doom Emacs, and I
spent an hour figuring out why elpy is not working. This is a direct result
of Doom being a third-party system. Emacs ecosystem is highly fractured. If
there was a first-class emacs distribution system, then elpy and elpy
tutorials would not be incompatible with it. Important things that have the
potential to break other stuff (modular emacs distribution, lsp support)
need to be implemented first-party so that the community can converge on
them. Here `first-party` means it should be endorsed by the core team, and
it should have some manpower dedicated to it.
On a sidenote, I just saw abo-abo's package for editing python a la lispy.
These REPL-centered, keyboard-first experience of editing code is emacs'
greatest strength and selling point to me, along its extensibility. I think
a more directed approach to unfracturing emacs users and making development
efforts of users more centralized to avoid duplication of efforts and
deliver preconfigured workflows that can be tweaked if need be, will go a
long way to revitalize emacs.

On another sidenote; The greatest weakness I see in VSCode is its culture.
The culture there does not see the value of extensibility, keyboard-first
workflows, interactive development, and generally investing in your tools
and shaping them to your needs.

On Wed, May 20, 2020 at 5:44 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 20.05.2020 16:10, João Távora wrote:
> > A non-appendix view would be: "I want to
> > work on my Python, C++, Go program" and go do that, not
> > caring about what was going on underneath at all, LSP, treesitter,
> > CC-mode if-then-elses, you name it.
>
> We won't be able to do this.
>
> IIRC the preceding discussion, we won't be allowed to even install
> language servers automatically.
>

[-- Attachment #2: Type: text/html, Size: 4290 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[Zach Pearson]

> On another sidenote; The greatest weakness I see in VSCode is its culture. The culture there does not see the value of extensibility, keyboard-first workflows, interactive development, and generally investing in your tools and shaping them to your needs. 

This is why I went with Emacs instead of any other editor. People keep calling VSCode “the millennial Emacs” but I don’t see it. 

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Monnier]

> ## Spacemacs
[...]
> ## Doom Emacs

Your comments remind me, that I think we (the "vanilla/core Emacs
community") should try and get more involved in this "Emacs
distribution" business.


        Stefan

GNU Emacs distribution (was: My perspective as a mid-level user on pros/cons of different editors)

[Thomas Fitzsimmons]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> ## Spacemacs
> [...]
>> ## Doom Emacs
>
> Your comments remind me, that I think we (the "vanilla/core Emacs
> community") should try and get more involved in this "Emacs
> distribution" business.

Yes, GNU Emacs World should be a vanilla/core community run Emacs
distribution that "vendors" the Free world.  Portacle [1] is an
interesting attempt in a similar direction, with a focus on Common Lisp.

Thomas

1. https://portacle.github.io/

Re: GNU Emacs distribution (was: My perspective as a mid-level user on pros/cons of different editors)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, GNU Emacs World should be a vanilla/core community run Emacs
  > distribution that "vendors" the Free world.

There are several terms in that sentence whose concrete meaning I
don't know.  Given the wide variability of what this might mean,
it could be an own-goal if we did it.  Or maybe not.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: My perspective as a mid-level user on pros/cons of different editors

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

+1. I think it would be very valuable for those involved in developing and
maintaining GNU Emacs to regularly try the various 'popular' distributions
and to try out other popular alternatives, like VSCode.

Some of the current popular Emacs distributions have some really good stuff
and some good ideas, some of which should probably be added into Emacs core
or provide guidelines on enhancements/improvements that would make it
possible to extend some of these ideas even further. I know that my own
personal Emacs config has benefited greatly from doing this - I've based a
lot of my setup on ideas I found in some of these distributions and found
out about some useful functionality I was not even aware of.

In a similar way, using other editors has also given me ideas for my Emacs
setup which has helped as well as some ideas for how I've dealt with some
issues in my packages/libs.



On Wed, 20 May 2020 at 22:26, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > ## Spacemacs
> [...]
> > ## Doom Emacs
>
> Your comments remind me, that I think we (the "vanilla/core Emacs
> community") should try and get more involved in this "Emacs
> distribution" business.
>
>
>         Stefan
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1868 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[tomas]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Thu, May 21, 2020 at 06:18:10AM +1000, Tim Cross wrote:
> +1. I think it would be very valuable for those involved in developing and
> maintaining GNU Emacs to regularly try the various 'popular' distributions
> and to try out other popular alternatives, like VSCode.

I'm glad Emacs maintainers... maintain Emacs, and do it so well,
and do it in their free time. I wouldn't dare to impose on them
using VSCode (unless they enjoy doing it; I wouldn't) or whatever
else.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[Stefan Monnier]

>> +1. I think it would be very valuable for those involved in developing and
>> maintaining GNU Emacs to regularly try the various 'popular' distributions
>> and to try out other popular alternatives, like VSCode.
>
> I'm glad Emacs maintainers... maintain Emacs, and do it so well,
> and do it in their free time. I wouldn't dare to impose on them
> using VSCode (unless they enjoy doing it; I wouldn't) or whatever
> else.

I don't think Tim meant to *impose* it ;-)


        Stefan

Re: My perspective as a mid-level user on pros/cons of different editors

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > +1. I think it would be very valuable for those involved in developing and
  > maintaining GNU Emacs to regularly try the various 'popular' distributions
  > and to try out other popular alternatives, like VSCode.

I wish I could do this.  But I work something like 12 hours a day and I still
can't do all the things it is my responsibility to do.  I am compelled
to depend on others to report to me the things I need to know.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: My perspective as a mid-level user on pros/cons of different editors

[ndame]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

> Of course, it takes more than making emacs viable to make it popular, but as things stand, emacs is not worth learning even for someone who wants to become a power user. It’s of course still worth it for those of us already invested in the platform (I personally use Doom Emacs plus my own config as my main editor), but NOT for new users. I fear that the situation will only get worse in the future, as VSCode enjoys both being a popular opensource project in the popular _javascript_ language, and a pet project of Microsoft.

Emacs can't really complete with VSCode, because it plays catch up in most areas (display, extension language, out of box the defaults, language support, etc.) and vscode is developed like crazy, it has a new release every month with new features and bugfixes:  [https://code.visualstudio.com/updates](https://code.visualstudio.com/updates/v1_45)

Emacs for me is more like a portable application platform where I can quickly create customized interfaces for various tasks regardless of the OS I use. E. g. if I want to display some information with interactive features to access an api, for example, then I use emacs, because for me it's much faster to make a GUI in emacs than making a GTK gui and then on windows having to install the GTK libs to use it, etc.  Emacs contains everything I need in a single package, so it's like my mini portable OS.

Emacs shines at this, though I don't know if there's a widespread demand for such usage. Maybe there is, just people don't know about it.

[-- Attachment #2: Type: text/html, Size: 1667 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[ndame]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

> As a user, I really want to be able to jump to
> eclaration/implementation/find references/get completion to work etc. I
> ouldn't care as slightest how it is implemented as long as it worked
> ell. Unfortunately (or fortunately) I know all the minutiae details on
> ow it works in my copy of Emacs since I had to install each and every
> acakge and configure them all together to get that working for me.
> hich indeed took quite some time untill I learned what I need, how to
> onfigure it and finally how to use it.

As you did it already how hard would it be you think to create a package which does this automatically?

I'm wondering why somebody hasn't made this already.

I don't mean a package in ELPA, but rather in MELPA, so the package is not restricted from downloading and installing a server, etc it could do anything what is needed to set up the configuration. Why aren't there packages for various languages which set up the completion/go to definition stuff automatically? Is there a technical problem?

[-- Attachment #2: Type: text/html, Size: 1248 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>> As a user, I really want to be able to jump to
>> eclaration/implementation/find references/get completion to work etc. I
>> ouldn't care as slightest how it is implemented as long as it worked
>> ell. Unfortunately (or fortunately) I know all the minutiae details on
>> ow it works in my copy of Emacs since I had to install each and every
>> acakge and configure them all together to get that working for me.
>> hich indeed took quite some time untill I learned what I need, how to
>> onfigure it and finally how to use it.
>
> As you did it already how hard would it be you think to create a package which does this automatically?
You mean like create a package that will just do a certain config and
pull in dependecnies and such? I guess not too hard.
>
> I'm wondering why somebody hasn't made this already. 
> I don't mean a package in ELPA, but rather in MELPA, so the package is not restricted from downloading and installing a server, etc it could do anything what is needed
> to set up the configuration. Why aren't there packages for various languages which set up the completion/go to definition stuff automatically? Is there a technical
> problem?

Because there are so many different paths to do this, old semantic and
autocomplete, newer lsp, company, etc. lsp vs ycmd, and so on. I don't
think there is a concensus on which one is best and what is best
approach to achieve this, all have some pros and cons. Also lots is
putting together pieces found on diverse blogs, configs etc. Maybe it
will change not that lsp mode gets more accepted?

Re: My perspective as a mid-level user on pros/cons of different editors

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please do not use GNU Project lists to advocate installing nonfree
programs.  Those programs are unjust, and when users install them,
they gives the developers power over them.

See https://gnu.org/philosophy/free-software-even-more-important.html
for an explanation of the issue.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: My perspective as a mid-level user on pros/cons of different editors

[chad]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

In addition to the philosophical reason, there's an effort-based reason,
and then there's the fact that it's a nasty combinatorics problem. Pick a
version of emacs (26 vs. 27 matters, although the setups probably don't
differ too much), then:
 for each language you want to support, (many)
 for each OS/version, (at least 3)
 for each method of installing non-elisp packages, (varies from "a couple"
to "half-dozen plus")
you *still* often have choices to make. This is probably also why the
typical "external tool install method" is a documentation line that says
something like "install ripgrep" or "make sure python-shell-interpreter and
py-shell-name are both set to python 3".


On Thu, May 21, 2020 at 2:55 AM ndame <ndame@protonmail.com> wrote:

> > As a user, I really want to be able to jump to
> > eclaration/implementation/find references/get completion to work etc. I
> > ouldn't care as slightest how it is implemented as long as it worked
> > ell. Unfortunately (or fortunately) I know all the minutiae details on
> > ow it works in my copy of Emacs since I had to install each and every
> > acakge and configure them all together to get that working for me.
> > hich indeed took quite some time untill I learned what I need, how to
> > onfigure it and finally how to use it.
>
> As you did it already how hard would it be you think to create a package
> which does this automatically?
>
> I'm wondering why somebody hasn't made this already.
>
> I don't mean a package in ELPA, but rather in MELPA, so the package is not
> restricted from downloading and installing a server, etc it could do
> anything what is needed to set up the configuration. Why aren't there
> packages for various languages which set up the completion/go to definition
> stuff automatically? Is there a technical problem?
>

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: My perspective as a mid-level user on pros/cons of different editors

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>  there's the fact that it's a nasty combinatorics problem. Pick a version of emacs (26 vs. 27 matters, although the setups probably don't differ too much), then:
>   for each language you want to support, (many)
>   for each OS/version, (at least 3)
>
> There is no need to solve all variations of the problem in one step.
>
> There could be packages like lsp-install-python-debian, lsp-install-javascript-windows, etc. where people would capture their experience of installing lsp support for the
> particular OS and language they use.  And when for a language there are variants for all major OSs then those could be packaged into a single parent package like
> lsp-install-python.
>
> The important thing is capturing the method installation for the variants which can be done separately and if they work reliably then it's not hard to put them into a
> single package.
>
> So people should start writing small packages of their particular installation variants and share those for other to use.

My personal setup is very slow, I don't care since I use emacs as server
and it started on boot, but I think my setup is too opinionated.

Personally I use combination of dumb-jump, lsp, additional syntax hight
packages and some scripts from emacs wiki to get my C/C++ mode more
usable. I don't have Java, Python etc configured, and I code very rarey
lately so my needs are relatively modest.I am sure it could be done more
on this front then what I have in my Emacs.

I do agree with tge idea to offer smaller "setup-packages", probably as
you say in Melpa, that people could just "(use-package lsp-c++-setup)"
and get decent "ide-like" features that we all setup individually. Emacs
package already has automatic dependency resolution if I understand
correctly so one could at least in theory automaticlly pull all the
stuff that is needed and configure it at least basically.

I see it as interest thing to try, but I am not sure if or when I
personally will or would have time to try to make something. I haven't
even have time to finnish my trivial suggestion to ls-switches in dired.
I will work on that one more next week though.