From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Herman, Geza" Newsgroups: gmane.emacs.bugs Subject: bug#64988: 30.0.50; move-to-column can move across lines if there is a text with display property Date: Tue, 1 Aug 2023 14:57:29 +0200 Message-ID: References: <5fc075c6-c94b-eacf-6bbd-7d337caa2ee7@gmail.com> <83o7jr0x0v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18181"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Cc: 64988@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 01 14:58:19 2023 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 1qQox9-0004Xa-3T for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Aug 2023 14:58:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQowu-0004Uz-Np; Tue, 01 Aug 2023 08:58:04 -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 1qQowt-0004Tu-HA for bug-gnu-emacs@gnu.org; Tue, 01 Aug 2023 08:58:03 -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 1qQowt-0005j2-4C for bug-gnu-emacs@gnu.org; Tue, 01 Aug 2023 08:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qQows-0003nI-AM for bug-gnu-emacs@gnu.org; Tue, 01 Aug 2023 08:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Herman, Geza" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Aug 2023 12:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64988 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug wontfix Original-Received: via spool by 64988-submit@debbugs.gnu.org id=B64988.169089466014554 (code B ref 64988); Tue, 01 Aug 2023 12:58:02 +0000 Original-Received: (at 64988) by debbugs.gnu.org; 1 Aug 2023 12:57:40 +0000 Original-Received: from localhost ([127.0.0.1]:47384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQowV-0003mg-FU for submit@debbugs.gnu.org; Tue, 01 Aug 2023 08:57:39 -0400 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]:53257) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQowS-0003mO-Pk for 64988@debbugs.gnu.org; Tue, 01 Aug 2023 08:57:37 -0400 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-522294c0d5bso7366770a12.2 for <64988@debbugs.gnu.org>; Tue, 01 Aug 2023 05:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690894651; x=1691499451; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=H5EbNoWwsSq5zGR/GaTQY6T/xVShj1gm2tg8HL1AnFo=; b=G+VZtmwQ1zz74tmR8ZnHiXF/dFjdQx2w+GcmuiSFloFEHSnMXaxpV+G+Tap6wFJwFj QpFeil2s4G2mQTFwzcs+rDyICf3p6t/EvsoOtJJPTidlXusAh/3D4iJXRJ0F5ZO8t8Z1 nZ7a9ZHfJ9iuwLXqPjVQ0SWfQQpWhxDs7cKNIeDpNmc5gOqRm0/9hzDdbtmCebIDAika Kj8X204XMyoL9NMj+SWJ+IJWUOz86MRqPGOSEIx/8PvLClhoCl6jT6cAksy03A4XDT5R Bcf8WycRkLolvJfau6lr9DTBC4U5lR2l5Ilq3i4rptvWp7GGXLz/XOJvAWrAZ22bSd7z /TxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690894651; x=1691499451; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=H5EbNoWwsSq5zGR/GaTQY6T/xVShj1gm2tg8HL1AnFo=; b=OplteqfpsiJgQHIqDNXMuWzwoIpeXPoPvYWy7q/yX999+lp08GfHj2z2ZVp2xUBalh 6I80yhUqQHGpj0TRGpSlJ0NopJg4BQ5PYcEwyWorBFYLEPanTjqXiDnSKQt9dG2JNpIO nKqmfh/2dQpqXeNCybgg4HDIu44uMFwnAkhVCA8CzITb2NL+OEgH90B+/FLzInYR9iL/ WrDfJ5J7UUd3GHR5UGQce5a4KzuPaWsNjopU549IACRD9YqW45e6athiVEaCYFPekWlH TlL5nhgYYP6O/ES9G6dhLOvqcI5kkKzX5rG1ejoMPIP94+wtbYgpXEaegMvcKz+Qozds 7QIw== X-Gm-Message-State: ABy/qLZRG20idlbSCf8Ynm6Qjt8Ov/IvQIT1VIuUEZQ+ljp7MvfslXiJ fWZcfslY0o1Y9QBXj69K/z2QT0jRPOU= X-Google-Smtp-Source: APBJJlFqWauwBkqNnNwr/PZIGRHUR5DAiailU0nrz/H02xBOndA9c4j8QiEvCGVM7cxGpA94IdRvEA== X-Received: by 2002:aa7:c309:0:b0:522:6e3f:b65 with SMTP id l9-20020aa7c309000000b005226e3f0b65mr2334656edq.33.1690894650570; Tue, 01 Aug 2023 05:57:30 -0700 (PDT) Original-Received: from [10.9.10.122] (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id y23-20020aa7c257000000b005226f281bc5sm6817054edo.25.2023.08.01.05.57.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Aug 2023 05:57:30 -0700 (PDT) Content-Language: en-US In-Reply-To: <83o7jr0x0v.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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266448 Archived-At: I think, in my case, the move-to-column should completely ignore the display property. Is there a function which does that? I noticed this problem because how indent-bars interacts with column-enforce-mode (https://github.com/jordonbiondo/column-enforce-mode). column-enforce-mode uses move-to-column to mark long lines. And because the display property with "\n" basically joins neighboring lines, column-enforce-mode marks lines incorrectly. I think it should only consider what's in the buffer, and ignore all rendering related properties. Is there a way to accomplish this? Regarding how to fix this problem: wouldn't it make sense to stop calculating the width at the first "\n" in the displayed string? At least, it would fix this problem, as far as I understand. Not sure if it breaks anything. But supposedly nothing should depend on the exact behavior of column calculations, if the displayed string contains characters after the first "\n" (because it's kind of undefined what the width of a multi-line string is) On 8/1/23 14:25, Eli Zaretskii wrote: > tags 64988 notabug wontfix > thanks > >> Date: Tue, 1 Aug 2023 12:53:57 +0200 >> From: Herman@debbugs.gnu.org, Géza >> >> If there is a text with display property in a buffer, then >> move-to-column can move across lines. >> >> Repro: >> * emacs -Q >> * in the scratch buffer, move the cursor to the top, and put an empty >> line at the beginning of the buffer >> * execute 'M-: (put-text-property 1 2 'display "line\n")' (note: it's >> likely that the "\n" causes the problem) >> * notice that the empty line becomes "line" >> * while the cursor still on the first line, execute 'M-: (move-to-column >> 20)' >> >> The last command will move the cursor to the next line at column 16, >> instead of staying at the first line. >> >> Note: I noticed this problem while using this package: >> https://github.com/jdtsmith/indent-bars. >> >> The problem doesn't happen with emacs 28, this is the commit that >> introduced the issue: >> >> 4243747b1b8c3b7e3463822804b32e83febe2878 Fix 'current-column' in the >> presence of display strings > This is a known issue, but it is not a bug, at least not one we know > how to "fix". In general, move-to-column cannot work correctly when > display strings with embedded newlines are involved, because Emacs > cannot place the cursor at the newline in the middle of such a display > string. > > The commit to which you point fixed current-column to correctly report > the column where such display strings are involved, at least in the > important cases. That move-to-column changed behavior in those cases > is unfortunate, but I couldn't find any sensible way of dealing with > these cases, because the correct result -- setting the cursor after > the newline embedded in the display string, because column 20 doesn't > exist on that line -- is impossible. (The result that you expected, > which was what Emacs 28 did, i.e. for the cursor to stay at buffer > position 1, is also incorrect, since that position is column 1, not > column 20 and not the last column visible on that line.) > > So I'm sorry, but unless someone comes with an idea for how to handle > these situations in a sensible way (and I thought long and hard about > it, but couldn't find such ideas), this will remain a limitation of > move-to-column, and one of the complications introduced by display > strings with embedded newlines in general. The affected packages will > have to adapt to this change in some ways. Since the original code > also produced incorrect results, just different incorrect results, I > don't see this as a serious problem, just as a bug that wasn't fixed, > but changed its buggy behavior.