From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sat, 5 Jun 2021 10:59:26 -0700 Message-ID: References: <831r9iw473.fsf@gnu.org> <87h7ieyma7.fsf@gmail.com> <15be7dd8-e901-e317-5111-e1a34f6f0416@gmail.com> <83k0n9l9pv.fsf@gnu.org> <83eedhl83r.fsf@gnu.org> <838s3olsok.fsf@gnu.org> <87lf7oy7vn.fsf@gmail.com> <20210605095904.vnyrph5n4lqooeyh@Ergus> <83o8ckk0s4.fsf@gnu.org> <83h7icjy2y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5005"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, spacibba@aol.com, theo@thornhill.no, ubolonton@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 05 20:00:07 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpaab-00015k-Dt for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Jun 2021 20:00:05 +0200 Original-Received: from localhost ([::1]:37630 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpaaY-0005CY-QI for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Jun 2021 14:00:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpaa2-0004Nf-7A for emacs-devel@gnu.org; Sat, 05 Jun 2021 13:59:30 -0400 Original-Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]:41600) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpaa0-0003L9-FQ; Sat, 05 Jun 2021 13:59:29 -0400 Original-Received: by mail-pg1-x52c.google.com with SMTP id r1so10459354pgk.8; Sat, 05 Jun 2021 10:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=LZDKUGfItlwHLQDA9g8LaJ279vmIk8HF3uYc+bg20/w=; b=lq3Z65YNiocOM6ZJ1AHoaaoOmbZ70HORMzojfYWwQI1UTgcNCzkQ1CF6JCA4X9wOzp GluWrYj3rc6TZHXK7taGQFai4EdI/d0tXRs3SaUtX1b8PKpHJzEUEIibZxOxkGp0lm2a hNNDeLs6E0OsH19RknR5Kor+tK2C76BlUru133OUy+s9dU1qRVjW5/zf9ogEZcmUiACK 6Y/QnwB8tJA6v1m3SGtm5zHYmDtSyFJfycxzbv9S92rXHkRM4HmhoGVI21P3gvXoOC8X WowT1wExAlLlWBQiZBULpb/mVykooHmImRjLF5Zk2UX+ionJo4xY2681AKUWnm2QndWX zZ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LZDKUGfItlwHLQDA9g8LaJ279vmIk8HF3uYc+bg20/w=; b=AtTob/65Zb2k5Wia1G3yyfzCYq6yaKVV9fOYZu36I1TACzSKbPU1OFmEBykxcuCw0h kibQRqrl1vnM0F2VUhhVPu1zYqTW/CiSlM/AysASfHYgMUq8lIfqSMWc/GgcTj4UcOHx nbbboC01W4HK8R686KFe0u1nr1LJwuMW9EeBYQXGJ6cLxt0sLwLIcufxHVkzuxkZcKTo 5ankvEUrCNIRTh8Fki5E+2E+mDZ9bRett3a8VwvAnEy/VmoRlyE+5h4MuAQulPHjiaGr jp41BLHC1yztl8QlmjmX3HERinKTWcrUjQQ95rJ4hV1YYWOq291xTZDjpcZuwPnTWk+e 0kJQ== X-Gm-Message-State: AOAM530lMPM+xoMUGgRwTugIBhKTl3j7gScZuPSa2U+hdivUltrQFHFH mCOclIXeR0g0CYV4Ep/3JuQ= X-Google-Smtp-Source: ABdhPJzkLtFeqoi+48lwdKjBmeCIOrOfIUpucfBJKEH5+EdzzFkwnw/eTxT9RnaZzZz+jMarxd7gpQ== X-Received: by 2002:a05:6a00:1742:b029:2cc:b1b0:731c with SMTP id j2-20020a056a001742b02902ccb1b0731cmr10278449pfc.15.1622915966175; Sat, 05 Jun 2021 10:59:26 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id p20sm4395681pff.204.2021.06.05.10.59.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 10:59:25 -0700 (PDT) In-Reply-To: <83h7icjy2y.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2607:f8b0:4864:20::52c; envelope-from=jporterbugs@gmail.com; helo=mail-pg1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270444 Archived-At: On 6/5/2021 5:27 AM, Eli Zaretskii wrote: >> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, ubolonton@gmail.com, >> theo@thornhill.no, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Sat, 5 Jun 2021 04:55:21 -0700 >> >> Fewer than running a remote Emacs: you don't interact with Tramp on each >> keystroke. There are tons of advantages to Tramp; it's a first-class >> feature and it's worth making language server support work properly with it. > > No argument that we need to support that properly. This sub-thread > started when someone said it would probably be slow with Tramp in the > loop. Just to clarify: it may turn out that communicating with a remote LSP server is fast enough for this purpose. However, if performance issues do crop up, they'll be more severe with TRAMP. Having used Eglot over TRAMP on a fast connection (within a LAN), nothing jumps out as annoyingly slow, although the things I use LSP for aren't latency-sensitive. It might be worth collecting some numbers on this to see how slow it really is. (As mentioned elsewhere in the thread, I'm very happy with how Eglot works with remote files currently, since it means that my dev tools for a particular environment can live on the same system as my source code. Having to run the appropriate LSP server locally to edit remote files would be inconvenient, although I suppose I could tolerate it.) Looking into this a bit more, I'm not actually 100% sure how much VSCode (or other LSP-aware editors) use LSP for syntax highlighting today. Semantic tokens are only available in the most recent specification of LSP (3.16)[1], so many LSP clients/servers likely wouldn't be using this yet. It might be helpful to see what they were doing prior to this; there may be some relatively non-invasive changes that could improve things. Perhaps there's a way to use something like tree-sitter (or even cc-mode as it currently stands) to get 90% of the way there and then augment that with results from the LSP server. For example, to address the original post, it seems the main issue is that cc-mode doesn't know what's a type and what isn't. If we could get type information from the LSP server, then cc-mode could take that into account. In the example, we could even rely on the fact that `std::variant' takes types as arguments, so we know that the arguments are types (or the code is incorrect). - Jim [1] https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_semanticTokens