From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#57433: Emacs no longer moves point into visible port of the buffer Date: Sat, 27 Aug 2022 16:07:49 +0200 Message-ID: References: <83y1vayqrm.fsf@gnu.org> <83v8qeypm5.fsf@gnu.org> <83sfliyonr.fsf@gnu.org> <83pmgmymdw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000009461905e7398f09" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16556"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 57433@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 27 16:09:10 2022 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 1oRwUo-0004BK-1q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 16:09:10 +0200 Original-Received: from localhost ([::1]:46822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRwUn-0002RW-2Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 10:09:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRwUg-0002RN-Hx for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 10:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38729) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRwUg-0000cG-9H for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 10:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRwUg-00050h-4i for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 10:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Aug 2022 14:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57433 X-GNU-PR-Package: emacs Original-Received: via spool by 57433-submit@debbugs.gnu.org id=B57433.166160929019200 (code B ref 57433); Sat, 27 Aug 2022 14:09:02 +0000 Original-Received: (at 57433) by debbugs.gnu.org; 27 Aug 2022 14:08:10 +0000 Original-Received: from localhost ([127.0.0.1]:56711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRwTp-0004zc-Is for submit@debbugs.gnu.org; Sat, 27 Aug 2022 10:08:09 -0400 Original-Received: from mail-ej1-f54.google.com ([209.85.218.54]:46852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRwTo-0004zR-8p for 57433@debbugs.gnu.org; Sat, 27 Aug 2022 10:08:08 -0400 Original-Received: by mail-ej1-f54.google.com with SMTP id bj12so7769184ejb.13 for <57433@debbugs.gnu.org>; Sat, 27 Aug 2022 07:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=7lArpK/SlX+mEV5gt5itJsDXfYyFWYnYJM0glxhKQKc=; b=L7X4Qufl9ogRqLFOFNC7wAO6vVU/FkSOLX4SRRhglDECtyudSv6g+J4r/g0RIq1iLZ PPQci4KUuKke5lH+AX7ybIIGAwM2b98M+K0bxc/HtcvN5JAKKNkwqjPWeze+wDuNiPRs tL9gbR5U4mEN2MxfJtsFpehrNxqmTac3kB+zEW3s4o7ZjfSMVKDTrprXJ9mry4E+s5BT Ne5x3mp0CpBinrlaDqkVFXZs5is/IE/xa6toiDxPNXRN4O4eC/vD/7jUngSzvBByScXs FrFJZ08i816oVzLslX/Ot4nH2a6j5KgvvljNDC/cfKPh7BHJoKuiG2V0n8m81PWEKCkl Jmuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=7lArpK/SlX+mEV5gt5itJsDXfYyFWYnYJM0glxhKQKc=; b=Hq+zFUynALfhisZRHi1kkeQH0MS+zZPU6AQTdZBG6aiWXEs9pOpOndHRwFBkJh2vo9 2uXyjeWIJNcqXVx4fUhDx+pXSN2xLjHK+zZKoare2df5gvAlFG4JKcXc5vRLYdJ/o8vv P2khlreSgynwTBNzvuZxcpYJTD6FSFYEx+IG9QhBhqd/sfyk0s8OzxhU4nSGpLZUu9dO wkHveb/Y6sr6V8kv2eqngid9IO9GcxIoIUksutVe/TCKf4hW0WFgR0KUpVRzl36yAAZ2 nefZlWxEILaPL8KV7gA5/wTlT9SsroRFLRdhqwJZQN4KD3p6bTEnLBcehXojiKlSkkEu 568g== X-Gm-Message-State: ACgBeo0gwOvzfJlwdi/QesQFsa+EcBTb4gafqTCZzERc/Fq7cRhWOY9x G+Awby5+SSi03qBDLFX6emxDirpd19g0bG9j0EguYNJ1dQ== X-Google-Smtp-Source: AA6agR712EVYockHfoovbXyveMIUTvozhc3FoyEppUJg1oIOUCjlopWG+0u9e5IaRY29s6Fjqb+gk92iRMntKoVackw= X-Received: by 2002:a17:907:b10:b0:73d:bedd:3121 with SMTP id h16-20020a1709070b1000b0073dbedd3121mr7915916ejl.530.1661609282453; Sat, 27 Aug 2022 07:08:02 -0700 (PDT) In-Reply-To: <83pmgmymdw.fsf@gnu.org> 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" Xref: news.gmane.io gmane.emacs.bugs:240924 Archived-At: --00000000000009461905e7398f09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Paul, please see that your original problem is now solved. No, don't see any change in behavior. > (Btw, I think it's a subtle bug in Magit that it assumes cursor motion > will never end up on invisible text in such buffers.) I don't think it is a bug. It is explicitly promised in Elisp manual as I see: > 22.6 Adjusting Point After Commands > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Emacs cannot display the cursor when point is in the middle of a > sequence of text that has the =E2=80=98display=E2=80=99 or =E2=80=98compo= sition=E2=80=99 property, or is > *invisible*. Therefore, after a command finishes and returns to the > command loop, if point is within such a sequence, the command loop > normally moves point to the edge of the sequence, making this sequence > effectively intangible. That's why, btw, I couldn't create a testcase: I don't know how to emulate command loop. Paul On Sat, 27 Aug 2022 at 13:08, Eli Zaretskii wrote: > > From: Gerd M=C3=B6llmann > > Cc: 57433@debbugs.gnu.org, pogonyshev@gmail.com > > Date: Sat, 27 Aug 2022 12:43:18 +0200 > > > > Eli Zaretskii writes: > > > > >> From: Gerd M=C3=B6llmann > > >> Cc: 57433@debbugs.gnu.org, pogonyshev@gmail.com > > >> Date: Sat, 27 Aug 2022 12:02:32 +0200 > > >> > > >> Eli Zaretskii writes: > > >> > > >> > Does Magit turn on truncate-lines in the affected buffer, or cause > > >> > them be truncated due to partial-width windows? If it does, I mig= ht > > >> > have an idea what could cause the OP's problem. > > >> > > >> Yes, truncate-lines it t. > > > > > > In that case, can you see if the patch below solves the original issu= e > > > with Magit? > > > > Works for me. Thanks! > > Thanks, installed. > > Paul, please see that your original problem is now solved. > > (Btw, I think it's a subtle bug in Magit that it assumes cursor motion > will never end up on invisible text in such buffers.) > --00000000000009461905e7398f09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Paul, please see that your original problem is now so= lved.

No, don't see any change in behavior.

> (Btw, I think it's a subtle bug in Magit that= it assumes cursor motion
> will never end up on invisible text in su= ch buffers.)

I don't think it is a bug. It= is explicitly promised in Elisp manual as I see:

= > 22.6 Adjusting Point After Commands
>=C2=A0=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>=C2=A0
>=C2=A0Emacs cannot display the cursor when p= oint is in the middle of a
>=C2=A0sequence of text that has the =E2= =80=98display=E2=80=99 or =E2=80=98composition=E2=80=99 property, or is
= >=C2=A0invisible.=C2=A0 Therefore, after a command finishes and r= eturns to the
>=C2=A0command loop, if point is within such a sequence= , the command loop
>=C2=A0normally moves point to the edge of the seq= uence, making this sequence
>=C2=A0effectively intangible.
<= div>
That's why, btw, I couldn't create a testcase: I= don't know how to emulate
command loop.

=
Paul

On Sat, 27 Aug 2022 at 13:08, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Gerd M=C3=B6llmann <gerd.moellmann@gmail= .com>
> Cc: 57433@d= ebbugs.gnu.org,=C2=A0 pogonyshev@gmail.com
> Date: Sat, 27 Aug 2022 12:43:18 +0200
>
> Eli Zaretskii <el= iz@gnu.org> writes:
>
> >> From: Gerd M=C3=B6llmann <gerd.moellmann@gmail.com>
> >> Cc: 57433@debbugs.gnu.org,=C2=A0 pogonyshev@gmail.com
> >> Date: Sat, 27 Aug 2022 12:02:32 +0200
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > Does Magit turn on truncate-lines in the affected buffer= , or cause
> >> > them be truncated due to partial-width windows?=C2=A0 If= it does, I might
> >> > have an idea what could cause the OP's problem.
> >>
> >> Yes, truncate-lines it t.
> >
> > In that case, can you see if the patch below solves the original = issue
> > with Magit?
>
> Works for me.=C2=A0 Thanks!

Thanks, installed.

Paul, please see that your original problem is now solved.

(Btw, I think it's a subtle bug in Magit that it assumes cursor motion<= br> will never end up on invisible text in such buffers.)
--00000000000009461905e7398f09--