From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer) Date: Sun, 5 May 2024 17:10:31 +0100 Message-ID: References: <86ttjr2pzw.fsf@gnu.org> <86edau3gyy.fsf@gnu.org> <8634ra36ny.fsf@gnu.org> <861q6ou2cs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d789b70617b72ef8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2533"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Copley , 70541-done@debbugs.gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 05 18:10:53 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1s3eRv-0000TM-Se for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 May 2024 18:10:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3eRn-0005tO-PO; Sun, 05 May 2024 12:10:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3eRj-0005sO-Ow for bug-gnu-emacs@gnu.org; Sun, 05 May 2024 12:10:39 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3eRi-0001UJ-A7 for bug-gnu-emacs@gnu.org; Sun, 05 May 2024 12:10:39 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s3eS5-0001Fw-K9 for bug-gnu-emacs@gnu.org; Sun, 05 May 2024 12:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 May 2024 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70541 X-GNU-PR-Package: emacs Original-Received: via spool by 70541-done@debbugs.gnu.org id=D70541.17149254304815 (code D ref 70541); Sun, 05 May 2024 16:11:01 +0000 Original-Received: (at 70541-done) by debbugs.gnu.org; 5 May 2024 16:10:30 +0000 Original-Received: from localhost ([127.0.0.1]:60453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3eRZ-0001Fb-O8 for submit@debbugs.gnu.org; Sun, 05 May 2024 12:10:30 -0400 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:58831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3eRT-0001FQ-Jj for 70541-done@debbugs.gnu.org; Sun, 05 May 2024 12:10:27 -0400 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-51f0b6b682fso1156836e87.1 for <70541-done@debbugs.gnu.org>; Sun, 05 May 2024 09:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714925393; x=1715530193; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xfVBQ4bKBnAdL4eiajWDH28/J7UblZai/Y/Wt164sJI=; b=VGFCaJqAg/KegJEv65fOQZ5qsd6rgA0OwmGdUqkPB3ec4sZrcQX+yjChOAUMSA4/Os 78wrKSI3OYL2ftuHvjbn5f7uavU1gue7cYbjrbY7R2d8lOVRjP/zJKQaXHSFmZTJp2pS WmUvnT47FTsAUvF/Dj6EMEzewE9lGTXYHXYHb8obWvuwtlZFXflSZnkvjuzxY9UyzELV uXrKubCpaxsM/6rhyT6eViHjJe1NCQ2nzQb47/KiLvOLw2LKmDomJEarEbzr0zsQCkMB aoKAKaILI/1Rqv6GmjnNVBMCTFjc/lxcy/zCu7EQSXbRGGyq80iNzmTQWVKdFSHI8tS3 WEfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714925393; x=1715530193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xfVBQ4bKBnAdL4eiajWDH28/J7UblZai/Y/Wt164sJI=; b=tAx23npjUYJAF2hDOpQ3q1dzMVW8ugFttmX+OGEL1oOBdhQmHRIo4XceMVwJn1f0rX 20Or8Y+87qCbZgV8XlHEED/vrxrU3y+dNCaF8YaYKP6nJsK0fw7xpvRlbMhinjXXt0RL NXlDYa3FKkyWlu2BztXA5YNzNbNqM51mWEGRf6Fwxw7EuwvBJc6aVGxpydY1BatiMyoU 9cjrjiSUOj7Squ1kSlt3U0dk9jNJHP5hIwukRRvoWYKOQPqs/s4I8QotnKV/2ue+QUGB IJU8cBEgi7+gdLdxYnbO2cPLxHxvly+gHPibKriCYcuTyCZEf5p55Cf8K6mDz4Zh/Hqa S3iQ== X-Forwarded-Encrypted: i=1; AJvYcCW5EGp8tauN+ZJBBFPnnXRrg7VQYHDye1Nbaf9V1c2KrZXiZkjK1ZTdsURfQbmwFIbwALmHWY8P9KQQsMhJjaCvoeXUSqWV9r1hFg== X-Gm-Message-State: AOJu0YyyJPNsKc+zxzYw4Fr/5cwlMfI7yz88vKcq3LHXuaNrAusjunJ3 oFkUnWm6SXOxpKRuh4dBN/ZG04LXLvtI0dUMoe1vuxNQ15bkUwYEO9xVXN8Kh4kKvKIyi1KlfYo 1xUqipkR2Le8I0o8kvkF+S5zEH0c= X-Google-Smtp-Source: AGHT+IEUw3kegNTzhGPJODAtsGLArt9XLLngRuKyK3UvvTAfr3iiQE+pGhgtcOaIIdnASxtBal9syM7WUvK3h8DDD/Y= X-Received: by 2002:a19:f60f:0:b0:51c:cc1b:a8f6 with SMTP id x15-20020a19f60f000000b0051ccc1ba8f6mr6049175lfe.20.1714925392592; Sun, 05 May 2024 09:09:52 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284508 Archived-At: --000000000000d789b70617b72ef8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 5, 2024 at 3:58=E2=80=AFPM Stefan Monnier wrote: > > Is this really the final word on this whole topic? The current > > solution involves a one shot addition to `post-command-hook` in Eglot > > and is really ugly. Can you really really no better solution so that > > Eglot is only compelled to send changes to the server once > > track-changes.el announces it safe to do so (and gives the change to > > send while it's at it? > > Until we've gotten rid of all the code chunks that incorrectly use > `inhibit-modification-hooks` (which will take a lot of time since not > only we have to find them but we have to figure out why they used > `inhibit-modification-hooks` and then argue hard to get the change to be > accepted), I don't see a significantly simpler solution, no. =F0=9F=99=81 > > I mean, a simpler solution is to live with the performance bug, of course= . > I don't know that this is a "performance bug". I mean, misleading the server, crashing it is only such a thing if one squints very hard. So while may be "significantly simpler" solution isn't in the cards, I still think some simplification can happen (I don't understand why post-command-hook needs to be used for example). Anyway, I would need to see the quil failure scenario encoded as a test in eglot-tests.el so I can have a clear shot at it. Should be possible, no? > > > Also, tangentially , can we get rid of the fboundp's and make the next > GNU > > ELPA version run the same code as Emacs master's by depending on > > track-changes.el GNU core? > > Yes, coming right up. > Thanks. That's great. It would also help to document your new eglot--track-changes-fetch. I'm afraid I've lost track of how the code is supposed to work after track-changes.el * why is :emacs-messup still a thing? By the way did :emacs-messup solve this very problem too via a full resync? * what exactly does the local eglot--track-changes do and why would it be re-registered in the same buffer (why isn't the typical add-hook enough). * There seems to be a track-changes.el signalling function and the longstanding LSP signalling function that informs the server of things. Why can't it be the same function, i.e. why can't Eglot tell track-changes.el to call Eglot's function when track-changes.el knows it's a safe time to call such a function? The flow of information via the eglot--recent-changes variable is complicated and would seem not worth bringing in track-changes.el at all. Is it only to accommodate Eglot versions when track-changes.el isn't available or is there some deeper reason? > > Also also, can you fix indentation in the function that you recently > > touched in Eglot? (same goes for Philip, but I'll contact him > > separately). > > Hmm... hadn't notice anything wrong. Will take a closer look, thanks > for the heads up. > Not serious, it's just I was misled by the misindentation when reading one of the new if's, thinking it only had a then branch. Jo=C3=A3o --000000000000d789b70617b72ef8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, May 5, 2024 at 3:58=E2=80=AFPM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Is this real= ly the final word on this whole topic?=C2=A0 =C2=A0The current
> solution involves a one shot addition to `post-command-hook` in Eglot<= br> > and is really ugly.=C2=A0 Can you really really no better solution so = that
> Eglot is only compelled to send changes to the server once
> track-changes.el announces it safe to do so (and gives the change to > send while it's at it?

Until we've gotten rid of all the code chunks that incorrectly use
`inhibit-modification-hooks` (which will take a lot of time since not
only we have to find them but we have to figure out why they used
`inhibit-modification-hooks` and then argue hard to get the change to be accepted), I don't see a significantly simpler solution, no. =F0=9F=99= =81

I mean, a simpler solution is to live with the performance bug, of course.<= br>

I don't know that this is a "p= erformance bug".=C2=A0 I mean, misleading the server,
crashi= ng it is only such a thing if one squints very hard.

So while may be "significantly simpler" solution isn't in = the cards,
I still think some simplification can happen (I don= 9;t understand
why post-command-hook needs to be used for example= ).

Anyway,=C2=A0 I would need to=C2=A0 see the qui= l failure scenario encoded as a=C2=A0
test in eglot-tests.el so I= can have a clear shot at it.=C2=A0 Should be
=C2=A0possible, no?=
=C2=A0
> Also also, can you fix indentation in the function that you recently > touched in Eglot? (same goes for Philip, but I'll contact him
> separately).

Hmm... hadn't notice anything wrong.=C2=A0 Will take a closer look, tha= nks
for the heads up.

Not serious, it's= just I was misled by the misindentation when reading=C2=A0
one o= f the new if's, thinking it only had a then branch.

Jo=C3=A3o
--000000000000d789b70617b72ef8--