EBrowse obsolete?

EBrowse obsolete?

[Gerd Möllmann]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 235 bytes --]

I see that ebrowse is still in Emacs, which is something I wrote ~30 
years ago.

I wonder if that is still useful to anyone?

Actually, in the time of language servers, ebrowse looks almost 
embarrasingly antiquated to me.



[-- Attachment #1.1.1.2: Type: text/html, Size: 551 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3211 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: EBrowse obsolete?

[Akib Azmain Turja]

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I see that ebrowse is still in Emacs, which is something I wrote ~30 years
> ago.
>
> I wonder if that is still useful to anyone?
>
> Actually, in the time of language servers, ebrowse looks almost
> embarrasingly antiquated to me.

Do we have a similar functionality in Eglot?  Though I use it, I'm not
sure, since I use it only for xref and completion.  If we have such
feature in Eglot, then I would suggest to first add Eglot to core Emacs
and then obsolete ebrowse.

And what about CEDET?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

CEDET obsolete? (was: Re: EBrowse obsolete?)

[Stefan Kangas]

Akib Azmain Turja <akib@disroot.org> writes:

> And what about CEDET?

CEDET is massive, but I guess at least a substantial part of it will
become irrelevant once eglot is added to core.

While we're at it, does it make sense to maintain both project.el and ede?

Re: CEDET obsolete?

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

> CEDET is massive, but I guess at least a substantial part of it will
> become irrelevant once eglot is added to core.
>
> While we're at it, does it make sense to maintain both project.el and ede?

Yes.  I use both every day for work.

Re: CEDET obsolete?

[Jose E. Marchesi]

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> And what about CEDET?
>
> CEDET is massive, but I guess at least a substantial part of it will
> become irrelevant once eglot is added to core.
>
> While we're at it, does it make sense to maintain both project.el and ede?

Does eglot work while offline?
semantic does.

Re: CEDET obsolete?

[Stefan Kangas]

Jose E. Marchesi <jemarch@gnu.org> writes:

> Does eglot work while offline?

Yes, of course.

Re: CEDET obsolete? (was: Re: EBrowse obsolete?)

[Lynn Winebarger]

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

On Thu, Jul 21, 2022, 8:51 AM Stefan Kangas <stefan@marxist.se> wrote:

> Akib Azmain Turja <akib@disroot.org> writes:
>
> > And what about CEDET?
>
> CEDET is massive, but I guess at least a substantial part of it will
> become irrelevant once eglot is added to core.


Why?  Emacs is still one of the most convenient editors for supporting
novel DSLs.  If anything, I'd like to be able to use Semantic to provide an
LSP server. Unfortunately, the documentation for developing language
support in Semantic is still missing some of the original document (never
made the migration), but that's solvable.

Lynn

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

Re: EBrowse obsolete?

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I see that ebrowse is still in Emacs, which is something I wrote ~30
> years ago.
>
> I wonder if that is still useful to anyone?

Yes, AFAIK recently someone reported a segfault in the parser that was
fixed.

> Actually, in the time of language servers, ebrowse looks almost
> embarrasingly antiquated to me.

Not everyone has the computing power to (or wants to) use a language
server.  And I'm not sure they provide the exact same features as
ebrowse does.

Re: EBrowse obsolete?

[Eli Zaretskii]

> Date: Thu, 21 Jul 2022 08:16:40 +0200
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> I see that ebrowse is still in Emacs, which is something I wrote ~30 years ago.
> 
> I wonder if that is still useful to anyone?
> 
> Actually, in the time of language servers, ebrowse looks almost embarrasingly antiquated to me.

Ebrowse is outdated and doesn't support current C++ standards.

It would be nice to have ebrowse updated to support the current level
of the C++ language, or at least close to that.  Language servers are
problematic for Emacs (I can say more if you are interested, but there
are lots of discussions to find on the Internet): their use is
relatively slow, and some of them present license-related issues.  In
any case, we don't yet have built-in support for them in Emacs (the
package Eglot is supposed to be that, but it is not yet in core).

So it would be nice to have a reasonably useful local solution, if
possible.  But if you think there's no hope for that to happen with
ebrowse, I won't object obsoleting ebrowse.c and ebrowse.el.

Re: EBrowse obsolete?

[Bozhidar Batsov]

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

Doesn't ECB offer pretty good support for C++ anyways? I'm not sure it's an alternative to EBrowse, but I recall when I was into C/C++ that was the package most Emacs users around me where using for browsing the codebase. Haven't used ECB in over a decade, though, so I'm not sure what's its status these days. 

On Thu, Jul 21, 2022, at 10:26 AM, Eli Zaretskii wrote:
> > Date: Thu, 21 Jul 2022 08:16:40 +0200
> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > 
> > I see that ebrowse is still in Emacs, which is something I wrote ~30 years ago.
> > 
> > I wonder if that is still useful to anyone?
> > 
> > Actually, in the time of language servers, ebrowse looks almost embarrasingly antiquated to me.
> 
> Ebrowse is outdated and doesn't support current C++ standards.
> 
> It would be nice to have ebrowse updated to support the current level
> of the C++ language, or at least close to that.  Language servers are
> problematic for Emacs (I can say more if you are interested, but there
> are lots of discussions to find on the Internet): their use is
> relatively slow, and some of them present license-related issues.  In
> any case, we don't yet have built-in support for them in Emacs (the
> package Eglot is supposed to be that, but it is not yet in core).
> 
> So it would be nice to have a reasonably useful local solution, if
> possible.  But if you think there's no hope for that to happen with
> ebrowse, I won't object obsoleting ebrowse.c and ebrowse.el.
> 
> 

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

Re: EBrowse obsolete?

[Zhiwei Chen]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Doesn't ECB offer pretty good support for C++ anyways? I'm not sure it's an alternative to EBrowse, but I recall when I was into
> C/C++ that was the package most Emacs users around me where using for browsing the codebase. Haven't used ECB in over a
> decade, though, so I'm not sure what's its status these days. 

ECB uses semantic, it's slower than lsp, needs complicate setups and unscalable.

-- 
Zhiwei Chen

Re: EBrowse obsolete?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> So it would be nice to have a reasonably useful local solution, if
> possible.  But if you think there's no hope for that to happen with
> ebrowse, I won't object obsoleting ebrowse.c and ebrowse.el.

I think we should keep ebrowse around, at least until a replacement
shows up.  It still works with code written for newer C++ standards,
just not supporting features specific to those new standards.

Most importantly, it exists, making it better than any potential
replacement.

Re: EBrowse obsolete?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> It would be nice to have ebrowse updated to support the current level
> of the C++ language, or at least close to that.  Language servers are
> problematic for Emacs (I can say more if you are interested, but there
> are lots of discussions to find on the Internet): their use is
> relatively slow, and some of them present license-related issues.  In
> any case, we don't yet have built-in support for them in Emacs (the
> package Eglot is supposed to be that, but it is not yet in core).

Okay, I'm not sure I wnat to know details, after searching for a GCC
language server, finding patches from 2017, and son on.

BTW.  I happened to try lsp-mode instead of eglot a week or two ago.  It
worked OOTB with Emacs' sources and clangd, which was already installed
on my system.  The only thing one needs is a tool for extracting a
compile_commands.json.  The first I tried, 'bear', also worked OOTB
("make clean; bear -- make" was enough).

No performance problems here, also.

> So it would be nice to have a reasonably useful local solution, if
> possible.  But if you think there's no hope for that to happen with
> ebrowse, I won't object obsoleting ebrowse.c and ebrowse.el.

Okay.

Re: EBrowse obsolete?

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Okay, I'm not sure I wnat to know details, after searching for a GCC
> language server, finding patches from 2017, and son on.
>
> BTW.  I happened to try lsp-mode instead of eglot a week or two ago.  It
> worked OOTB with Emacs' sources and clangd, which was already installed
> on my system.  The only thing one needs is a tool for extracting a
> compile_commands.json.  The first I tried, 'bear', also worked OOTB
> ("make clean; bear -- make" was enough).
>
> No performance problems here, also.

I guess you're using a Mac.  Macs have clangd preinstalled and set up
for Mac OS development.

It isn't so easy to use clangd on GNU/Linux.  The first thing it does is
to make my two-processor machine very slow.  Then I have to struggle
with include paths to make it find stddef.h in the right place.

Re: EBrowse obsolete?

[Dmitry Gutov]

On 21.07.2022 14:44, Po Lu wrote:
> It isn't so easy to use clangd on GNU/Linux.  The first thing it does is
> to make my two-processor machine very slow.  Then I have to struggle
> with include paths to make it find stddef.h in the right place.

FWIW, GNU/Linux systems are on average faster than Macs, historically, 
especially if one compares laptops which cost the same.

Even if said GNU/Linux runs on a Mac hardware, it's either faster or 
comparable: 
https://www.phoronix.com/scan.php?page=article&item=macos12-windows-linux&num=1

(M1 situation aside, of course).

That's not to say someone can't have an inexpensive or dated GNU/Linux 
system which struggles with LLVM or other programs.

Re: EBrowse obsolete?

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> I guess you're using a Mac.  Macs have clangd preinstalled and set up
> for Mac OS development.

Yes, I'm using a Mac, and it has a /usr/bin/clangd that comes with Xcode
(Apple's IDE).

One can use that clangd, I've done that, and it works.  But I'm actually
using the clangd from "brew install llvm", which is newer than Apple's.

The M1 chip has 8 cores, though.

Re: EBrowse obsolete?

[Akib Azmain Turja]

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

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Okay, I'm not sure I wnat to know details, after searching for a GCC
>> language server, finding patches from 2017, and son on.
>>
>> BTW.  I happened to try lsp-mode instead of eglot a week or two ago.  It
>> worked OOTB with Emacs' sources and clangd, which was already installed
>> on my system.  The only thing one needs is a tool for extracting a
>> compile_commands.json.  The first I tried, 'bear', also worked OOTB
>> ("make clean; bear -- make" was enough).
>>
>> No performance problems here, also.
>
> I guess you're using a Mac.  Macs have clangd preinstalled and set up
> for Mac OS development.
>
> It isn't so easy to use clangd on GNU/Linux.  The first thing it does is
> to make my two-processor machine very slow.  Then I have to struggle
> with include paths to make it find stddef.h in the right place.
>

Yes, I also couldn't make clangd work, but ccls works good.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: EBrowse obsolete?

[Yuri Khan]

On Thu, 21 Jul 2022 at 19:43, Akib Azmain Turja <akib@disroot.org> wrote:

> Yes, I also couldn't make clangd work, but ccls works good.

Data point: I couldn’t make clangd work the first time I tried it, and
I thought ccls worked ~good~ well. Then I did another attempt at
clangd and it worked even better. (As in, ccls takes some noticeable
time to start up to a usable state, but clangd starts working
instantly. Both take a lot of memory/swap space though.)

Re: EBrowse obsolete?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2022 13:12:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It would be nice to have ebrowse updated to support the current level
> > of the C++ language, or at least close to that.  Language servers are
> > problematic for Emacs (I can say more if you are interested, but there
> > are lots of discussions to find on the Internet): their use is
> > relatively slow, and some of them present license-related issues.  In
> > any case, we don't yet have built-in support for them in Emacs (the
> > package Eglot is supposed to be that, but it is not yet in core).
> 
> Okay, I'm not sure I wnat to know details, after searching for a GCC
> language server, finding patches from 2017, and son on.
> 
> BTW.  I happened to try lsp-mode instead of eglot a week or two ago.  It
> worked OOTB with Emacs' sources and clangd, which was already installed
> on my system.  The only thing one needs is a tool for extracting a
> compile_commands.json.  The first I tried, 'bear', also worked OOTB
> ("make clean; bear -- make" was enough).
> 
> No performance problems here, also.

Sheer luck, AFAIU.  I've seen many complaints about that (JSON
deserialization being the main issue, but not the only one), and the
need to install clangd is frowned upon by GNU.  Using LSP via the
network solves that part, but it's slower, AFAIU.

Re: EBrowse obsolete?

[Dmitry Gutov]

On 21.07.2022 15:15, Eli Zaretskii wrote:
> I've seen many complaints about that (JSON
> deserialization being the main issue, but not the only one)

Didn't we mostly solve that in Emacs 27.1?

Re: EBrowse obsolete?

[Eli Zaretskii]

> Date: Thu, 21 Jul 2022 15:19:16 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 21.07.2022 15:15, Eli Zaretskii wrote:
> > I've seen many complaints about that (JSON
> > deserialization being the main issue, but not the only one)
> 
> Didn't we mostly solve that in Emacs 27.1?

Not if my reading of Reddit is correct.  We definitely improved
things, though, and quite a lot.  But using a server over the network
will never be as performant as a local solution.

Re: EBrowse obsolete?

[Stefan Monnier]

> Not if my reading of Reddit is correct.  We definitely improved
> things, though, and quite a lot.  But using a server over the network
> will never be as performant as a local solution.

AFAIK most uses of LSP are local (no network involved).


        Stefan

Re: EBrowse obsolete?

[Visuwesh]

[வியாழன் ஜூலை 21, 2022] Stefan Monnier wrote:

>> Not if my reading of Reddit is correct.  We definitely improved
>> things, though, and quite a lot.  But using a server over the network
>> will never be as performant as a local solution.
>
> AFAIK most uses of LSP are local (no network involved).
>

Surprisingly, complaints about running LSP over TRAMP comes up really
often in Reddit.

Re: EBrowse obsolete?

[Stefan Monnier]

Visuwesh [2022-07-21 21:46:24] wrote:
> [வியாழன் ஜூலை 21, 2022] Stefan Monnier wrote:
>>> Not if my reading of Reddit is correct.  We definitely improved
>>> things, though, and quite a lot.  But using a server over the network
>>> will never be as performant as a local solution.
>> AFAIK most uses of LSP are local (no network involved).
> Surprisingly, complaints about running LSP over TRAMP comes up really
> often in Reddit.

Ah, so that's what you mean by "over the network".  I'm surprised it
comes up that often.  I don't think it's a super-common use case
(e.g. what other editor offers such a functionality?  What do non-Emacs
users do when they have such a need?).  I suspect there's some strong
bias in the "measurement".  Maybe it shows up much more often simply
because the other use cases "just work".


        Stefan

Re: EBrowse obsolete?

[Visuwesh]

[வியாழன் ஜூலை 21, 2022] Stefan Monnier wrote:

> Visuwesh [2022-07-21 21:46:24] wrote:
>> [வியாழன் ஜூலை 21, 2022] Stefan Monnier wrote:
>>>> Not if my reading of Reddit is correct.  We definitely improved
>>>> things, though, and quite a lot.  But using a server over the network
>>>> will never be as performant as a local solution.
>>> AFAIK most uses of LSP are local (no network involved).
>> Surprisingly, complaints about running LSP over TRAMP comes up really
>> often in Reddit.
>
> Ah, so that's what you mean by "over the network".  I'm surprised it
> comes up that often.  I don't think it's a super-common use case

That's what I thought too, but in every discussion about LSP (or
lsp-mode v. eglot), people never fail to mention performance over TRAMP.

> (e.g. what other editor offers such a functionality?  What do non-Emacs
> users do when they have such a need?).

My memory is fuzzy here, but I think people just ssh?  I believe VSCode
has something similar to TRAMP (which was remarked to be much "smoother"
and "better OOTB" than TRAMP) but I have no idea about its interaction
wrt LSP.

> I suspect there's some strong bias in the "measurement".  Maybe it
> shows up much more often simply because the other use cases "just
> work".

Another thing that Reddit does a lot is complain about how slow/clunky
TRAMP is.  Sometimes this seems to be solved by actually reading the
TRAMP FAQ/manual (like setting the remote server's prompt to something
sane, etc.).  Take this with a grain of salt because (a) I've only ever
used the doas TRAMP method and (b) my memory is fuzzy since I don't use
LSP myself and hence I don't care too much about these discussions.

Re: EBrowse obsolete?

[Jim Porter]

On 7/21/2022 9:51 AM, Stefan Monnier wrote:
> Visuwesh [2022-07-21 21:46:24] wrote:
>> Surprisingly, complaints about running LSP over TRAMP comes up really
>> often in Reddit.
> 
> Ah, so that's what you mean by "over the network".  I'm surprised it
> comes up that often.  I don't think it's a super-common use case
> (e.g. what other editor offers such a functionality?  What do non-Emacs
> users do when they have such a need?).

I don't use VS Code myself, but from talking with people who do, my 
understanding is that it supports LSP over SSH. (VS Code is a bit 
different in that it requires you to install a specific VS Code server 
on the remote host though, so maybe the closest analogy in Emacs would 
really be using emacsclient over TCP.)

For what it's worth, I do a *lot* of editing over Tramp and have tried 
Eglot-over-Tramp in the past. It mostly works, but it does require a bit 
of fiddling, since it seems to occasionally trigger a race condition in 
Tramp code. I vaguely recall a WIP Tramp branch that improved the 
reentrancy of Tramp code which might fix this, but I'm sure that's 
pretty tricky to get 100% right.

- Jim

Re: EBrowse obsolete?

[Stefan Monnier]

> I don't use VS Code myself, but from talking with people who do, my
> understanding is that it supports LSP over SSH. (VS Code is a bit different
> in that it requires you to install a specific VS Code server on the remote
> host though, so maybe the closest analogy in Emacs would really be using
> emacsclient over TCP.)

Indeed, I don't think we can hope to get good performance with an
approach like that of Tramp which works hard to try and avoid requiring
installation of a "Emacs server" on the other end.
This said, it's probably possible to make it "good enough" in most
cases, tho it may require extra work.

For Emacs, an "easy" solution is to run Emacs on the remote side and
only have the display part be local (e.g. `ssh <host> emacs`), but in
some cases installation (and configuration) of Emacs on the remote side
is not really an option (either because of constraints on the remote
side, or because you want to have a single Emacs session that accesses
several remote hosts, or ...).

I wonder how they split the work between VSCode's servers and clients.

[ Reminds me that I've wished for an Emacs where the `buffer_text`
  object is remote, so you can open a 10GB remote file, navigate
  inside of it, and edit it without having to transfer the whole 10GB.  ]


        Stefan

Re: EBrowse obsolete?

[Jim Porter]

On 7/21/2022 10:39 AM, Stefan Monnier wrote:
>> I don't use VS Code myself, but from talking with people who do, my
>> understanding is that it supports LSP over SSH. (VS Code is a bit different
>> in that it requires you to install a specific VS Code server on the remote
>> host though, so maybe the closest analogy in Emacs would really be using
>> emacsclient over TCP.)
> 
> Indeed, I don't think we can hope to get good performance with an
> approach like that of Tramp which works hard to try and avoid requiring
> installation of a "Emacs server" on the other end.
> This said, it's probably possible to make it "good enough" in most
> cases, tho it may require extra work.

I think there are probably two separate (but somewhat related) issues:

1. LSP over Tramp is "slow". I'm sure there are things we can do to make 
Tramp faster, especially with "well-behaved" remote hosts. For example, 
maybe Tramp can get more info about a host upon connection and then use 
that to avoid some work later on.

2. LSP over Tramp is "unreliable". I think this is the more-pressing 
issue. It's one thing if a remote request takes longer than expected, 
but another thing entirely if it just fails to work every so often. When 
trying to use Eglot + Tramp on some larger projects, I'd get hit with 
"Forbidden reentrant call of Tramp" every so often, which, if memory 
serves, usually required a bit of poking at Eglot, or at least retrying 
the operation I wanted to do. Maybe this has improved since the last 
time I tried this, but (I think) fixing these errors would go a long way 
towards resolving people's complaints. That's probably easier said than 
done though...

Re: EBrowse obsolete?

[Tim Cross]

Jim Porter <jporterbugs@gmail.com> writes:

> On 7/21/2022 10:39 AM, Stefan Monnier wrote:
>>> I don't use VS Code myself, but from talking with people who do, my
>>> understanding is that it supports LSP over SSH. (VS Code is a bit different
>>> in that it requires you to install a specific VS Code server on the remote
>>> host though, so maybe the closest analogy in Emacs would really be using
>>> emacsclient over TCP.)
>> Indeed, I don't think we can hope to get good performance with an
>> approach like that of Tramp which works hard to try and avoid requiring
>> installation of a "Emacs server" on the other end.
>> This said, it's probably possible to make it "good enough" in most
>> cases, tho it may require extra work.
>
> I think there are probably two separate (but somewhat related) issues:
>
> 1. LSP over Tramp is "slow". I'm sure there are things we can do to make Tramp faster,
> especially with "well-behaved" remote hosts. For example, maybe Tramp can get more info
> about a host upon connection and then use that to avoid some work later on.
>
> 2. LSP over Tramp is "unreliable". I think this is the more-pressing issue. It's one thing
> if a remote request takes longer than expected, but another thing entirely if it just
> fails to work every so often. When trying to use Eglot + Tramp on some larger projects,
> I'd get hit with "Forbidden reentrant call of Tramp" every so often, which, if memory
> serves, usually required a bit of poking at Eglot, or at least retrying the operation I
> wanted to do. Maybe this has improved since the last time I tried this, but (I think)
> fixing these errors would go a long way towards resolving people's complaints. That's
> probably easier said than done though...

I use to use tramp a lot. However, these days, I only use it for ad hoc
editing.

What I found worked much better and took a lot less configuration was to
use FUSE to mount a local ssh filesystem of the remote repository and
then just edit it as if it was local. I would then just use an ssh
session inside emacs to execute/run things.

Having said that, since the growth in git/hg, the amount of remote
editing I need to do has dropped significantly. This combined with the
increased availability of various 'containers' means these days I'm much
more likely to spin up a local development environment. This also has
the huge advantage of allowing me to work off line or when moving around
where I'm connected to many different networks (a scenario where remote
access control can become a PITA).

I do have the advantage of working on a GNU Emacs system and as all of
the software I work on runs on GNU LInux, setting up a local development
environment is straight-forward (i.e. have access to databases, web
servers, compilers, etc).

Re: EBrowse obsolete?

[Michael Albinus]

Tim Cross <theophilusx@gmail.com> writes:

Hi Tim,

> What I found worked much better and took a lot less configuration was to
> use FUSE to mount a local ssh filesystem of the remote repository and
> then just edit it as if it was local. I would then just use an ssh
> session inside emacs to execute/run things.

FTR, Tramp has implemented this. The method is called "sshfs" (surprise :-)

Using Tramp with this method avoids your need to configure the sshfs
connection manually. Additionally, it allows you in Emacs to call remote
processes on the remote host, which wouldn't be possible with just a
manual configured sshfs.

Best regards, Michael.

Re: EBrowse obsolete?

[Tim Cross]

Michael Albinus <michael.albinus@gmx.de> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
> Hi Tim,
>
>> What I found worked much better and took a lot less configuration was to
>> use FUSE to mount a local ssh filesystem of the remote repository and
>> then just edit it as if it was local. I would then just use an ssh
>> session inside emacs to execute/run things.
>
> FTR, Tramp has implemented this. The method is called "sshfs" (surprise :-)
>
> Using Tramp with this method avoids your need to configure the sshfs
> connection manually. Additionally, it allows you in Emacs to call remote
> processes on the remote host, which wouldn't be possible with just a
> manual configured sshfs.
>

Thanks, that is useful to know.

Re: EBrowse obsolete?

[Brian Cully via Emacs development discussions.]

Jim Porter <jporterbugs@gmail.com> writes:

> When trying to use Eglot + Tramp on some larger projects, I'd
> get hit with "Forbidden reentrant call of Tramp" every so often,
> which, if memory serves, usually required a bit of poking at 
> Eglot, or
> at least retrying the operation I wanted to do. Maybe this has
> improved since the last time I tried this, but (I think) fixing 
> these
> errors would go a long way towards resolving people's
> complaints. That's probably easier said than done though...

I use Eglot over Tramp exclusively, since it allows me to set up 
containers with isolated and predictable environments. It's a very 
important feature for me, which is why I submitted the initial 
patch that made it possible. I would *love* to fix the “forbidden 
re-entrant call to Tramp” problem, but I honestly have no idea 
how. I've tried before, but debugging this particular facet of 
Tramp's behavior is extremely challenging for me: it's very 
inconsistent, and I haven't figured out a way to see the chain of 
events that's setting it off.

I also suspect it's a larger problem than Eglot: I also see the 
error fairly regularly in eshell sessions on remote hosts.

I'm more than willing to put some work in here if I can get some 
useful pointers; I *love* Tramp, and this is my only real 
annoyance with it right now.

-bjc

Re: EBrowse obsolete?

[Jim Porter]

On 7/22/2022 7:29 AM, Brian Cully via Emacs development discussions. wrote:
> I use Eglot over Tramp exclusively, since it allows me to set up 
> containers with isolated and predictable environments. It's a very 
> important feature for me, which is why I submitted the initial patch 
> that made it possible. I would *love* to fix the “forbidden re-entrant 
> call to Tramp” problem, but I honestly have no idea how.
[snip]
> I'm more than willing to put some work in here if I can get some useful 
> pointers; I *love* Tramp, and this is my only real annoyance with it 
> right now.

This thread on tramp-devel has some information that might help point 
you in the right direction: 
<https://lists.gnu.org/archive/html/tramp-devel/2021-04/msg00034.html>. 
Michael Albinus had been working on a thread-safe Tramp that would 
resolve this, but it stalled.

In particular, one of the blockers to fixing this would be figuring out 
a way for code in an Emacs thread to prompt the user (see bug#25214). 
Normally, I don't think prompting the user should happen with Tramp + 
Eglot, but it's always possible (e.g. if you need to re-enter your 
password), and it looks like things fail pretty hard with the 
thread-safe Tramp if that happens.

Re: EBrowse obsolete?

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> In particular, one of the blockers to fixing this would be figuring
> out a way for code in an Emacs thread to prompt the user (see
> bug#25214). Normally, I don't think prompting the user should happen
> with Tramp + Eglot, but it's always possible (e.g. if you need to
> re-enter your password), and it looks like things fail pretty hard
> with the thread-safe Tramp if that happens.

It's not only the password prompt. Dialogues like

(y-or-n-p (format "File %s exists; overwrite anyway?" filename))

could always happen.

Best regards, Michael.

Re: EBrowse obsolete?

[Michael Albinus]

Brian Cully via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

Hi Brian,

> I use Eglot over Tramp exclusively, since it allows me to set up
> containers with isolated and predictable environments. It's a very
> important feature for me, which is why I submitted the initial patch
> that made it possible. I would *love* to fix the “forbidden re-entrant
> call to Tramp” problem, but I honestly have no idea how. I've tried
> before, but debugging this particular facet of Tramp's behavior is
> extremely challenging for me: it's very inconsistent, and I haven't
> figured out a way to see the chain of events that's setting it off.
>
> I also suspect it's a larger problem than Eglot: I also see the error
> fairly regularly in eshell sessions on remote hosts.
>
> I'm more than willing to put some work in here if I can get some
> useful pointers; I *love* Tramp, and this is my only real annoyance
> with it right now.

There is the branch feature/tramp-thread-safe in Emacs git. It hasn't
been updated for more than 2 years :-( But you could start with this and
see whether it works better for you with Eglot.

I'll try to merge it with the recent master when time permits.

> -bjc

Best regards, Michael.

Re: EBrowse obsolete?

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> I think there are probably two separate (but somewhat related) issues:
>
> 1. LSP over Tramp is "slow". I'm sure there are things we can do to
> make Tramp faster, especially with "well-behaved" remote hosts. For
> example, maybe Tramp can get more info about a host upon connection
> and then use that to avoid some work later on.

What Tramp can do is to start the remote LSP server
faster. Occasionally, I've been in contact with both the glot and the
lsp-mose people, and I've proposed to use the "direct async process"
feature of Tramp, see

(info "(tramp)Improving performance of asynchronous remote processes")

Personally, I don't use lsp servers, so I have no idea whether this
recommendation got attention.

> 2. LSP over Tramp is "unreliable". I think this is the more-pressing
> issue. It's one thing if a remote request takes longer than expected,
> but another thing entirely if it just fails to work every so
> often. When trying to use Eglot + Tramp on some larger projects, I'd
> get hit with "Forbidden reentrant call of Tramp" every so often,
> which, if memory serves, usually required a bit of poking at Eglot, or
> at least retrying the operation I wanted to do. Maybe this has
> improved since the last time I tried this, but (I think) fixing these
> errors would go a long way towards resolving people's
> complaints. That's probably easier said than done though...

This is a general problem. Whenever a remote operation is triggered
asynchronously, from a timer, a process-filter, or process-sentinel,
this operation can be in conflict with another remote operation just in
process. Tramp detects this, and raises a warning, and refuses to
perform this asynchronous operation. One could instruct Tramp to ignore
this error by

(setq debug-ignored-errors
      (cons 'remote-file-error debug-ignored-errors))

But since the remote operation is not performed, it is likely that the
lsp servers won't work correctly then.

Re: EBrowse obsolete?

[Michael Albinus]

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

Hi Stefan,

>> I don't use VS Code myself, but from talking with people who do, my
>> understanding is that it supports LSP over SSH. (VS Code is a bit different
>> in that it requires you to install a specific VS Code server on the remote
>> host though, so maybe the closest analogy in Emacs would really be using
>> emacsclient over TCP.)
>
> Indeed, I don't think we can hope to get good performance with an
> approach like that of Tramp which works hard to try and avoid requiring
> installation of a "Emacs server" on the other end.

FTR, there are proposals to use a remote Emacs instance as server. This
approach sounds interesting, but due to the disadvantages, and the
amount of work, I've never tired a prototype.

> This said, it's probably possible to make it "good enough" in most
> cases, tho it may require extra work.

Sigh.

> [ Reminds me that I've wished for an Emacs where the `buffer_text`
>   object is remote, so you can open a 10GB remote file, navigate
>   inside of it, and edit it without having to transfer the whole 10GB.  ]

Hmm. Could you please elaborate a little bit, how this ought to work?
Unless there is a remote Emacs instance?

>         Stefan

Best regards, Michael.

Re: EBrowse obsolete?

[Stefan Monnier]

>> Indeed, I don't think we can hope to get good performance with an
>> approach like that of Tramp which works hard to try and avoid requiring
>> installation of a "Emacs server" on the other end.
>
> FTR, there are proposals to use a remote Emacs instance as server. This
> approach sounds interesting, but due to the disadvantages, and the
> amount of work, I've never tired a prototype.

The issue is not just what's running on the remote host, but what's the
protocol between the two (not just at the byte-level but in terms of
what kinds of operations/data/events go back and forth).

Tramp's flexibility depends on the design of `file-name-handlers-alist`.
In some cases (such as a quick edit to a very large remote file), that's
a very significant restriction.

>> [ Reminds me that I've wished for an Emacs where the `buffer_text`
>>   object is remote, so you can open a 10GB remote file, navigate
>>   inside of it, and edit it without having to transfer the whole 10GB.  ]
> Hmm. Could you please elaborate a little bit, how this ought to work?
> Unless there is a remote Emacs instance?

I was taking it for granted that the remote host would be running some
Emacs-specific server, yes.  I think that'd be the easy part :-)
The harder part is to decide which operations should take place on which
side, and what information to send when between the two sides.  [ And of
course, actually writing the code to make it work without breaking too
much existing uses nor significantly slowing down the normal local
use case.  ]


        Stefan

Re: EBrowse obsolete?

[Michael Albinus]

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

Hi Stefan,

>>> Indeed, I don't think we can hope to get good performance with an
>>> approach like that of Tramp which works hard to try and avoid requiring
>>> installation of a "Emacs server" on the other end.
>>
>> FTR, there are proposals to use a remote Emacs instance as server. This
>> approach sounds interesting, but due to the disadvantages, and the
>> amount of work, I've never tired a prototype.
>
> The issue is not just what's running on the remote host, but what's the
> protocol between the two (not just at the byte-level but in terms of
> what kinds of operations/data/events go back and forth).

I've discussed this a while ago with Mattias Engdegård. His proposal was
to have a protocol on sexp level, that means the client sends

(file-exists-p localname)

and the remote server responds with

t

On both sides, the Lisp reader would be active.

> Tramp's flexibility depends on the design of `file-name-handlers-alist`.
> In some cases (such as a quick edit to a very large remote file), that's
> a very significant restriction.

Sure, but we're able to extend the file-name-handler-alist protocol. For
example by a function which is activated by a remote default-directory,
and sends local file names, being relative or absolute, back and forth.

This wouldn't even need a remote Emacs server, but only a proper
implementation in Tramp and other file name handlers.

> I was taking it for granted that the remote host would be running some
> Emacs-specific server, yes.  I think that'd be the easy part :-)
> The harder part is to decide which operations should take place on which
> side, and what information to send when between the two sides.  [ And of
> course, actually writing the code to make it work without breaking too
> much existing uses nor significantly slowing down the normal local
> use case.  ]

Yep. But we could do it iteratively: Add magic functions as needed. To
be honest, I do it already internally. Tramp's list of magic functions
is extended by (taken from tramp-sh.el)

    (tramp-get-home-directory . tramp-sh-handle-get-home-directory)
    (tramp-get-remote-gid . tramp-sh-handle-get-remote-gid)
    (tramp-get-remote-uid . tramp-sh-handle-get-remote-uid)
    (tramp-set-file-uid-gid . tramp-sh-handle-set-file-uid-gid)

Simply, because there are different implementations for different Tramp
backends, and the mechanism is available :-) Other, non-Tramp file name
handlers are not affected, because every file name handler, which is
called for a function it doesn't know, falls back to the default
implementation.

So if you have a function `my-own-bulk-operation', which looks for a
handler of it in case of a remote default directory, it would do. (Well,
Tramp is a bit of picky for the functions, and it shall at least know
that there is such a magic function -- otherwise, it moans).

>         Stefan

Best regards, Michael.

Re: EBrowse obsolete?

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

> On 7/21/2022 9:51 AM, Stefan Monnier wrote:
>> Visuwesh [2022-07-21 21:46:24] wrote:
>>> Surprisingly, complaints about running LSP over TRAMP comes up really
>>> often in Reddit.
>> Ah, so that's what you mean by "over the network".  I'm surprised it
>> comes up that often.  I don't think it's a super-common use case
>> (e.g. what other editor offers such a functionality?  What do non-Emacs
>> users do when they have such a need?).
>
> I don't use VS Code myself, but from talking with people who do, my
> understanding is that it supports LSP over SSH. (VS Code is a bit
> different in that it requires you to install a specific VS Code server
> on the remote host though, so maybe the closest analogy in Emacs would
> really be using emacsclient over TCP.)

Indeed, VS Code uses a remote server for that, see
<https://code.visualstudio.com/docs/remote/remote-overview>. It does not
require you to install it manually, adding the "Remote Development
extension pack" does the trick. This installs the remote VS Code server
on the remote host when needed.

OTOH, Tramp uses a remote shell as a REPL engine. That is another
approach, and less performant.

(In the past I've tried to use remote Perl or Python programs as REPL
engine, but the performance was even worse).

> For what it's worth, I do a *lot* of editing over Tramp and have tried
> Eglot-over-Tramp in the past. It mostly works, but it does require a
> bit of fiddling, since it seems to occasionally trigger a race
> condition in Tramp code. I vaguely recall a WIP Tramp branch that
> improved the reentrancy of Tramp code which might fix this, but I'm
> sure that's pretty tricky to get 100% right.

Yes.

> - Jim

Best regards, Michael.

Re: EBrowse obsolete?

[Po Lu]

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

> Ah, so that's what you mean by "over the network".  I'm surprised it
> comes up that often.  I don't think it's a super-common use case
> (e.g. what other editor offers such a functionality?

Apparently, VS Code and some IntelliJ products.

Re: EBrowse obsolete?

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Ah, so that's what you mean by "over the network".  I'm surprised it
>> comes up that often.  I don't think it's a super-common use case
>> (e.g. what other editor offers such a functionality?
>
> Apparently, VS Code and some IntelliJ products.

Also worth mentioning are Netbeans, Eclipse, CLion, some Python IDEs...

My impression is that remote development got a lot of traction when
working in home office became more popular/neccessary--companies usually
don't want their source code on private computers.  In some cases there
might also be legal or contractual requirements for this.

Re: EBrowse obsolete?

[tomas]

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

On Fri, Jul 22, 2022 at 06:55:33AM +0200, Gerd Möllmann wrote:
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >
> >> Ah, so that's what you mean by "over the network".  I'm surprised it
> >> comes up that often.  I don't think it's a super-common use case
> >> (e.g. what other editor offers such a functionality?
> >
> > Apparently, VS Code and some IntelliJ products.
> 
> Also worth mentioning are Netbeans, Eclipse, CLion, some Python IDEs...
> 
> My impression is that remote development got a lot of traction when
> working in home office became more popular/neccessary--companies usually
> don't want their source code on private computers.  In some cases there
> might also be legal or contractual requirements for this.

I rather think it is the current bout of containeritis. But it might be
both.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: EBrowse obsolete?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Visuwesh
>  <visuweshm@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov
>  <dgutov@yandex.ru>,  emacs-devel@gnu.org
> Date: Fri, 22 Jul 2022 06:55:33 +0200
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >
> >> Ah, so that's what you mean by "over the network".  I'm surprised it
> >> comes up that often.  I don't think it's a super-common use case
> >> (e.g. what other editor offers such a functionality?
> >
> > Apparently, VS Code and some IntelliJ products.
> 
> Also worth mentioning are Netbeans, Eclipse, CLion, some Python IDEs...

Volunteers are welcome on working on such facilities for Emacs, of
course.

Re: EBrowse obsolete?

[Tim Cross]

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

>> Not if my reading of Reddit is correct.  We definitely improved
>> things, though, and quite a lot.  But using a server over the network
>> will never be as performant as a local solution.
>
> AFAIK most uses of LSP are local (no network involved).
>
>

Yes, that has been my experience with a few different languages. The
server runs locally (you could connect to a remote one if desired, but
many of these servers are small and trivial to install, so just as easy
to run it locally). In at least a couple of the servers I've used, all
the 'server' really does is provide a consistent interface across a
number of other distinct tools (linters, document lookup services,
language parser, completion, etc). In the past, I would have achieved almost the
identical outcome by installing all these separate tools and then
configuring Emacs interfaces to them i.e. flymake/flycheck, xref, eldoc, company
etc. Now I just configure lsp-mode or eglot and I'm done. Getting a
reasonably 'modern' environment working with LSP has certainly been
easier for me than it was previously, but I suspect a lot depends on the
languages your working with and the maturity of the servers for those
languages. There were definitely some issues with lsp-mode initially,
but I've found it very stable and effective in recent months. I also
find eglot promising, but it still seems a ways behind lsp-mode, which
is not surprising given the differences in age and user numbers. I do
prefer eglot because of its closer integration with Emacs (also why I'v
moved away from ivy/company to vertico/embark/corfu). 

Re: EBrowse obsolete?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Sheer luck, AFAIU.  I've seen many complaints about that (JSON
> deserialization being the main issue, but not the only one), and the
> need to install clangd is frowned upon by GNU.  Using LSP via the
> network solves that part, but it's slower, AFAIU.

Let the Gnu frown.

Every language server for C/C++ I could find so far is based on Clang.
I'd be grateful for pointers to a language server for C/C++ that's based
on GCC.

Re: EBrowse obsolete?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2022 14:58:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sheer luck, AFAIU.  I've seen many complaints about that (JSON
> > deserialization being the main issue, but not the only one), and the
> > need to install clangd is frowned upon by GNU.  Using LSP via the
> > network solves that part, but it's slower, AFAIU.
> 
> Let the Gnu frown.
> 
> Every language server for C/C++ I could find so far is based on Clang.
> I'd be grateful for pointers to a language server for C/C++ that's based
> on GCC.

This is a tangent.  No one expects a tool like Ebrowse to compete with
language servers.  OTOH, for such a simple job, a language server is
not really needed.

We _are_ working on getting a client for language servers into Emacs
(we decided to bring Eglot into core), it just takes time (patches are
welcome, btw).  But that's a much larger job, and will enable many
more features, than a tool for browsing C++ code.

Re: EBrowse obsolete?

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Every language server for C/C++ I could find so far is based on Clang.
> I'd be grateful for pointers to a language server for C/C++ that's based
> on GCC.

I hope someone will finish and upstream the patches to GCC that
implement a language server.

They have existed since 2017, but it seems nobody has done work since
then.