* EBrowse obsolete? @ 2022-07-21 6:16 Gerd Möllmann 2022-07-21 6:44 ` Akib Azmain Turja ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Gerd Möllmann @ 2022-07-21 6:16 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 6:16 EBrowse obsolete? Gerd Möllmann @ 2022-07-21 6:44 ` Akib Azmain Turja 2022-07-21 12:46 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Stefan Kangas 2022-07-21 6:49 ` EBrowse obsolete? Po Lu 2022-07-21 7:26 ` Eli Zaretskii 2 siblings, 1 reply; 48+ messages in thread From: Akib Azmain Turja @ 2022-07-21 6:44 UTC (permalink / raw) To: Gerd Möllmann; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* CEDET obsolete? (was: Re: EBrowse obsolete?) 2022-07-21 6:44 ` Akib Azmain Turja @ 2022-07-21 12:46 ` Stefan Kangas 2022-07-21 13:00 ` CEDET obsolete? Po Lu ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Stefan Kangas @ 2022-07-21 12:46 UTC (permalink / raw) To: Akib Azmain Turja; +Cc: Gerd Möllmann, Emacs developers 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: CEDET obsolete? 2022-07-21 12:46 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Stefan Kangas @ 2022-07-21 13:00 ` Po Lu 2022-07-22 10:26 ` Jose E. Marchesi 2022-07-23 11:44 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Lynn Winebarger 2 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-21 13:00 UTC (permalink / raw) To: Stefan Kangas; +Cc: Akib Azmain Turja, Gerd Möllmann, Emacs developers 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: CEDET obsolete? 2022-07-21 12:46 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Stefan Kangas 2022-07-21 13:00 ` CEDET obsolete? Po Lu @ 2022-07-22 10:26 ` Jose E. Marchesi 2022-07-22 13:26 ` Stefan Kangas 2022-07-23 11:44 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Lynn Winebarger 2 siblings, 1 reply; 48+ messages in thread From: Jose E. Marchesi @ 2022-07-22 10:26 UTC (permalink / raw) To: Stefan Kangas; +Cc: Akib Azmain Turja, Gerd Möllmann, Emacs developers > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: CEDET obsolete? 2022-07-22 10:26 ` Jose E. Marchesi @ 2022-07-22 13:26 ` Stefan Kangas 0 siblings, 0 replies; 48+ messages in thread From: Stefan Kangas @ 2022-07-22 13:26 UTC (permalink / raw) To: Jose E. Marchesi; +Cc: Akib Azmain Turja, Gerd Möllmann, Emacs developers Jose E. Marchesi <jemarch@gnu.org> writes: > Does eglot work while offline? Yes, of course. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: CEDET obsolete? (was: Re: EBrowse obsolete?) 2022-07-21 12:46 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Stefan Kangas 2022-07-21 13:00 ` CEDET obsolete? Po Lu 2022-07-22 10:26 ` Jose E. Marchesi @ 2022-07-23 11:44 ` Lynn Winebarger 2 siblings, 0 replies; 48+ messages in thread From: Lynn Winebarger @ 2022-07-23 11:44 UTC (permalink / raw) To: Stefan Kangas; +Cc: Akib Azmain Turja, Gerd Möllmann, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 6:16 EBrowse obsolete? Gerd Möllmann 2022-07-21 6:44 ` Akib Azmain Turja @ 2022-07-21 6:49 ` Po Lu 2022-07-21 7:26 ` Eli Zaretskii 2 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-21 6:49 UTC (permalink / raw) To: Gerd Möllmann; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 6:16 EBrowse obsolete? Gerd Möllmann 2022-07-21 6:44 ` Akib Azmain Turja 2022-07-21 6:49 ` EBrowse obsolete? Po Lu @ 2022-07-21 7:26 ` Eli Zaretskii 2022-07-21 7:56 ` Bozhidar Batsov ` (2 more replies) 2 siblings, 3 replies; 48+ messages in thread From: Eli Zaretskii @ 2022-07-21 7:26 UTC (permalink / raw) To: Gerd Möllmann; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 7:26 ` Eli Zaretskii @ 2022-07-21 7:56 ` Bozhidar Batsov 2022-07-21 12:16 ` Zhiwei Chen 2022-07-21 8:16 ` Po Lu 2022-07-21 11:12 ` Gerd Möllmann 2 siblings, 1 reply; 48+ messages in thread From: Bozhidar Batsov @ 2022-07-21 7:56 UTC (permalink / raw) To: Emacs Devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 7:56 ` Bozhidar Batsov @ 2022-07-21 12:16 ` Zhiwei Chen 0 siblings, 0 replies; 48+ messages in thread From: Zhiwei Chen @ 2022-07-21 12:16 UTC (permalink / raw) To: Bozhidar Batsov; +Cc: Emacs Devel "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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 7:26 ` Eli Zaretskii 2022-07-21 7:56 ` Bozhidar Batsov @ 2022-07-21 8:16 ` Po Lu 2022-07-21 11:12 ` Gerd Möllmann 2 siblings, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-21 8:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Gerd Möllmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 7:26 ` Eli Zaretskii 2022-07-21 7:56 ` Bozhidar Batsov 2022-07-21 8:16 ` Po Lu @ 2022-07-21 11:12 ` Gerd Möllmann 2022-07-21 11:44 ` Po Lu 2022-07-21 12:15 ` Eli Zaretskii 2 siblings, 2 replies; 48+ messages in thread From: Gerd Möllmann @ 2022-07-21 11:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 11:12 ` Gerd Möllmann @ 2022-07-21 11:44 ` Po Lu 2022-07-21 12:21 ` Dmitry Gutov ` (2 more replies) 2022-07-21 12:15 ` Eli Zaretskii 1 sibling, 3 replies; 48+ messages in thread From: Po Lu @ 2022-07-21 11:44 UTC (permalink / raw) To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 11:44 ` Po Lu @ 2022-07-21 12:21 ` Dmitry Gutov 2022-07-21 12:28 ` Gerd Möllmann 2022-07-21 12:33 ` Akib Azmain Turja 2 siblings, 0 replies; 48+ messages in thread From: Dmitry Gutov @ 2022-07-21 12:21 UTC (permalink / raw) To: Po Lu, Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 11:44 ` Po Lu 2022-07-21 12:21 ` Dmitry Gutov @ 2022-07-21 12:28 ` Gerd Möllmann 2022-07-21 12:33 ` Akib Azmain Turja 2 siblings, 0 replies; 48+ messages in thread From: Gerd Möllmann @ 2022-07-21 12:28 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 11:44 ` Po Lu 2022-07-21 12:21 ` Dmitry Gutov 2022-07-21 12:28 ` Gerd Möllmann @ 2022-07-21 12:33 ` Akib Azmain Turja 2022-07-21 17:02 ` Yuri Khan 2 siblings, 1 reply; 48+ messages in thread From: Akib Azmain Turja @ 2022-07-21 12:33 UTC (permalink / raw) To: Po Lu; +Cc: Gerd Möllmann, Eli Zaretskii, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:33 ` Akib Azmain Turja @ 2022-07-21 17:02 ` Yuri Khan 0 siblings, 0 replies; 48+ messages in thread From: Yuri Khan @ 2022-07-21 17:02 UTC (permalink / raw) To: Akib Azmain Turja Cc: Po Lu, Gerd Möllmann, Eli Zaretskii, Emacs developers 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.) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 11:12 ` Gerd Möllmann 2022-07-21 11:44 ` Po Lu @ 2022-07-21 12:15 ` Eli Zaretskii 2022-07-21 12:19 ` Dmitry Gutov 2022-07-21 12:58 ` Gerd Möllmann 1 sibling, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2022-07-21 12:15 UTC (permalink / raw) To: Gerd Möllmann; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:15 ` Eli Zaretskii @ 2022-07-21 12:19 ` Dmitry Gutov 2022-07-21 12:28 ` Eli Zaretskii 2022-07-21 12:58 ` Gerd Möllmann 1 sibling, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2022-07-21 12:19 UTC (permalink / raw) To: Eli Zaretskii, Gerd Möllmann; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:19 ` Dmitry Gutov @ 2022-07-21 12:28 ` Eli Zaretskii 2022-07-21 15:21 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2022-07-21 12:28 UTC (permalink / raw) To: Dmitry Gutov; +Cc: gerd.moellmann, emacs-devel > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:28 ` Eli Zaretskii @ 2022-07-21 15:21 ` Stefan Monnier 2022-07-21 16:16 ` Visuwesh 2022-07-22 1:35 ` Tim Cross 0 siblings, 2 replies; 48+ messages in thread From: Stefan Monnier @ 2022-07-21 15:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Dmitry Gutov, gerd.moellmann, emacs-devel > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 15:21 ` Stefan Monnier @ 2022-07-21 16:16 ` Visuwesh 2022-07-21 16:51 ` Stefan Monnier 2022-07-22 1:35 ` Tim Cross 1 sibling, 1 reply; 48+ messages in thread From: Visuwesh @ 2022-07-21 16:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel [வியாழன் ஜூலை 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 16:16 ` Visuwesh @ 2022-07-21 16:51 ` Stefan Monnier 2022-07-21 17:07 ` Visuwesh ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Stefan Monnier @ 2022-07-21 16:51 UTC (permalink / raw) To: Visuwesh; +Cc: Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 16:51 ` Stefan Monnier @ 2022-07-21 17:07 ` Visuwesh 2022-07-21 17:16 ` Jim Porter 2022-07-22 1:06 ` Po Lu 2 siblings, 0 replies; 48+ messages in thread From: Visuwesh @ 2022-07-21 17:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel [வியாழன் ஜூலை 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 16:51 ` Stefan Monnier 2022-07-21 17:07 ` Visuwesh @ 2022-07-21 17:16 ` Jim Porter 2022-07-21 17:39 ` Stefan Monnier 2022-07-23 9:51 ` Michael Albinus 2022-07-22 1:06 ` Po Lu 2 siblings, 2 replies; 48+ messages in thread From: Jim Porter @ 2022-07-21 17:16 UTC (permalink / raw) To: Stefan Monnier, Visuwesh Cc: Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 17:16 ` Jim Porter @ 2022-07-21 17:39 ` Stefan Monnier 2022-07-21 21:26 ` Jim Porter 2022-07-23 9:57 ` Michael Albinus 2022-07-23 9:51 ` Michael Albinus 1 sibling, 2 replies; 48+ messages in thread From: Stefan Monnier @ 2022-07-21 17:39 UTC (permalink / raw) To: Jim Porter Cc: Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 17:39 ` Stefan Monnier @ 2022-07-21 21:26 ` Jim Porter 2022-07-22 2:01 ` Tim Cross ` (2 more replies) 2022-07-23 9:57 ` Michael Albinus 1 sibling, 3 replies; 48+ messages in thread From: Jim Porter @ 2022-07-21 21:26 UTC (permalink / raw) To: Stefan Monnier Cc: Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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... ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 21:26 ` Jim Porter @ 2022-07-22 2:01 ` Tim Cross 2022-07-23 10:18 ` Michael Albinus 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. 2022-07-23 10:13 ` Michael Albinus 2 siblings, 1 reply; 48+ messages in thread From: Tim Cross @ 2022-07-22 2:01 UTC (permalink / raw) To: emacs-devel 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 2:01 ` Tim Cross @ 2022-07-23 10:18 ` Michael Albinus 2022-07-24 23:25 ` Tim Cross 0 siblings, 1 reply; 48+ messages in thread From: Michael Albinus @ 2022-07-23 10:18 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-23 10:18 ` Michael Albinus @ 2022-07-24 23:25 ` Tim Cross 0 siblings, 0 replies; 48+ messages in thread From: Tim Cross @ 2022-07-24 23:25 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 21:26 ` Jim Porter 2022-07-22 2:01 ` Tim Cross @ 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. 2022-07-22 17:22 ` Jim Porter 2022-07-23 10:28 ` Michael Albinus 2022-07-23 10:13 ` Michael Albinus 2 siblings, 2 replies; 48+ messages in thread From: Brian Cully via Emacs development discussions. @ 2022-07-22 14:29 UTC (permalink / raw) To: Jim Porter Cc: Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. @ 2022-07-22 17:22 ` Jim Porter 2022-07-23 10:35 ` Michael Albinus 2022-07-23 10:28 ` Michael Albinus 1 sibling, 1 reply; 48+ messages in thread From: Jim Porter @ 2022-07-22 17:22 UTC (permalink / raw) To: Brian Cully Cc: Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 17:22 ` Jim Porter @ 2022-07-23 10:35 ` Michael Albinus 0 siblings, 0 replies; 48+ messages in thread From: Michael Albinus @ 2022-07-23 10:35 UTC (permalink / raw) To: Jim Porter Cc: Brian Cully, Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. 2022-07-22 17:22 ` Jim Porter @ 2022-07-23 10:28 ` Michael Albinus 1 sibling, 0 replies; 48+ messages in thread From: Michael Albinus @ 2022-07-23 10:28 UTC (permalink / raw) To: Brian Cully via Emacs development discussions. Cc: Jim Porter, Brian Cully, Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 21:26 ` Jim Porter 2022-07-22 2:01 ` Tim Cross 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. @ 2022-07-23 10:13 ` Michael Albinus 2 siblings, 0 replies; 48+ messages in thread From: Michael Albinus @ 2022-07-23 10:13 UTC (permalink / raw) To: Jim Porter Cc: Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 17:39 ` Stefan Monnier 2022-07-21 21:26 ` Jim Porter @ 2022-07-23 9:57 ` Michael Albinus 2022-07-23 14:36 ` Stefan Monnier 1 sibling, 1 reply; 48+ messages in thread From: Michael Albinus @ 2022-07-23 9:57 UTC (permalink / raw) To: Stefan Monnier Cc: Jim Porter, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-23 9:57 ` Michael Albinus @ 2022-07-23 14:36 ` Stefan Monnier 2022-07-23 15:04 ` Michael Albinus 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2022-07-23 14:36 UTC (permalink / raw) To: Michael Albinus Cc: Jim Porter, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-23 14:36 ` Stefan Monnier @ 2022-07-23 15:04 ` Michael Albinus 0 siblings, 0 replies; 48+ messages in thread From: Michael Albinus @ 2022-07-23 15:04 UTC (permalink / raw) To: Stefan Monnier Cc: Jim Porter, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel, Mattias Engdegård 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 17:16 ` Jim Porter 2022-07-21 17:39 ` Stefan Monnier @ 2022-07-23 9:51 ` Michael Albinus 1 sibling, 0 replies; 48+ messages in thread From: Michael Albinus @ 2022-07-23 9:51 UTC (permalink / raw) To: Jim Porter Cc: Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 16:51 ` Stefan Monnier 2022-07-21 17:07 ` Visuwesh 2022-07-21 17:16 ` Jim Porter @ 2022-07-22 1:06 ` Po Lu 2022-07-22 4:55 ` Gerd Möllmann 2 siblings, 1 reply; 48+ messages in thread From: Po Lu @ 2022-07-22 1:06 UTC (permalink / raw) To: Stefan Monnier Cc: Visuwesh, Eli Zaretskii, Dmitry Gutov, gerd.moellmann, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 1:06 ` Po Lu @ 2022-07-22 4:55 ` Gerd Möllmann 2022-07-22 5:15 ` tomas 2022-07-22 6:52 ` Eli Zaretskii 0 siblings, 2 replies; 48+ messages in thread From: Gerd Möllmann @ 2022-07-22 4:55 UTC (permalink / raw) To: Po Lu; +Cc: Stefan Monnier, Visuwesh, Eli Zaretskii, Dmitry Gutov, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 4:55 ` Gerd Möllmann @ 2022-07-22 5:15 ` tomas 2022-07-22 6:52 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: tomas @ 2022-07-22 5:15 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-22 4:55 ` Gerd Möllmann 2022-07-22 5:15 ` tomas @ 2022-07-22 6:52 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2022-07-22 6:52 UTC (permalink / raw) To: Gerd Möllmann; +Cc: luangruo, monnier, visuweshm, dgutov, emacs-devel > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 15:21 ` Stefan Monnier 2022-07-21 16:16 ` Visuwesh @ 2022-07-22 1:35 ` Tim Cross 1 sibling, 0 replies; 48+ messages in thread From: Tim Cross @ 2022-07-22 1:35 UTC (permalink / raw) To: emacs-devel 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:15 ` Eli Zaretskii 2022-07-21 12:19 ` Dmitry Gutov @ 2022-07-21 12:58 ` Gerd Möllmann 2022-07-21 13:04 ` Eli Zaretskii 2022-07-21 13:16 ` Po Lu 1 sibling, 2 replies; 48+ messages in thread From: Gerd Möllmann @ 2022-07-21 12:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:58 ` Gerd Möllmann @ 2022-07-21 13:04 ` Eli Zaretskii 2022-07-21 13:16 ` Po Lu 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2022-07-21 13:04 UTC (permalink / raw) To: Gerd Möllmann; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: EBrowse obsolete? 2022-07-21 12:58 ` Gerd Möllmann 2022-07-21 13:04 ` Eli Zaretskii @ 2022-07-21 13:16 ` Po Lu 1 sibling, 0 replies; 48+ messages in thread From: Po Lu @ 2022-07-21 13:16 UTC (permalink / raw) To: Gerd Möllmann; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2022-07-24 23:25 UTC | newest] Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-21 6:16 EBrowse obsolete? Gerd Möllmann 2022-07-21 6:44 ` Akib Azmain Turja 2022-07-21 12:46 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Stefan Kangas 2022-07-21 13:00 ` CEDET obsolete? Po Lu 2022-07-22 10:26 ` Jose E. Marchesi 2022-07-22 13:26 ` Stefan Kangas 2022-07-23 11:44 ` CEDET obsolete? (was: Re: EBrowse obsolete?) Lynn Winebarger 2022-07-21 6:49 ` EBrowse obsolete? Po Lu 2022-07-21 7:26 ` Eli Zaretskii 2022-07-21 7:56 ` Bozhidar Batsov 2022-07-21 12:16 ` Zhiwei Chen 2022-07-21 8:16 ` Po Lu 2022-07-21 11:12 ` Gerd Möllmann 2022-07-21 11:44 ` Po Lu 2022-07-21 12:21 ` Dmitry Gutov 2022-07-21 12:28 ` Gerd Möllmann 2022-07-21 12:33 ` Akib Azmain Turja 2022-07-21 17:02 ` Yuri Khan 2022-07-21 12:15 ` Eli Zaretskii 2022-07-21 12:19 ` Dmitry Gutov 2022-07-21 12:28 ` Eli Zaretskii 2022-07-21 15:21 ` Stefan Monnier 2022-07-21 16:16 ` Visuwesh 2022-07-21 16:51 ` Stefan Monnier 2022-07-21 17:07 ` Visuwesh 2022-07-21 17:16 ` Jim Porter 2022-07-21 17:39 ` Stefan Monnier 2022-07-21 21:26 ` Jim Porter 2022-07-22 2:01 ` Tim Cross 2022-07-23 10:18 ` Michael Albinus 2022-07-24 23:25 ` Tim Cross 2022-07-22 14:29 ` Brian Cully via Emacs development discussions. 2022-07-22 17:22 ` Jim Porter 2022-07-23 10:35 ` Michael Albinus 2022-07-23 10:28 ` Michael Albinus 2022-07-23 10:13 ` Michael Albinus 2022-07-23 9:57 ` Michael Albinus 2022-07-23 14:36 ` Stefan Monnier 2022-07-23 15:04 ` Michael Albinus 2022-07-23 9:51 ` Michael Albinus 2022-07-22 1:06 ` Po Lu 2022-07-22 4:55 ` Gerd Möllmann 2022-07-22 5:15 ` tomas 2022-07-22 6:52 ` Eli Zaretskii 2022-07-22 1:35 ` Tim Cross 2022-07-21 12:58 ` Gerd Möllmann 2022-07-21 13:04 ` Eli Zaretskii 2022-07-21 13:16 ` Po Lu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).