From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#61361: cursor cannot be at the start of overlay that starts with a newline Date: Wed, 08 Feb 2023 17:50:29 +0200 Message-ID: <83h6vwnol6.fsf@gnu.org> References: <83o7q4nw2s.fsf@gnu.org> <83k00snqhp.fsf@gnu.org> <05087da5-30d3-dbb5-1dd7-70acf050b37d@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24827"; mail-complaints-to="usenet@ciao.gmane.io" Cc: chenxy@mit.edu, 61361@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 08 16:51:12 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 1pPmj2-0006D0-Az for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Feb 2023 16:51:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPmit-00045J-Uz; Wed, 08 Feb 2023 10:51:03 -0500 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 1pPmis-00044t-AM for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:51:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pPmis-0007UA-2L for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pPmir-0003w2-Kn for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:51:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Feb 2023 15:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61361 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 61361-submit@debbugs.gnu.org id=B61361.167587142515076 (code B ref 61361); Wed, 08 Feb 2023 15:51:01 +0000 Original-Received: (at 61361) by debbugs.gnu.org; 8 Feb 2023 15:50:25 +0000 Original-Received: from localhost ([127.0.0.1]:56409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPmiH-0003v5-9C for submit@debbugs.gnu.org; Wed, 08 Feb 2023 10:50:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPmiF-0003uo-4d for 61361@debbugs.gnu.org; Wed, 08 Feb 2023 10:50:24 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPmi8-0006rE-Sh; Wed, 08 Feb 2023 10:50:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Iu9/4YyWXIUNuXPp1xAuecmR5AkZwkuDeWAkTQ1Zz4A=; b=rgFSF26ByO9a bNYGx5sec5mU7MNQBeZUChLSZhGEkm+scm4exTyqMo2P919gCPUhRCkCqTIFNqB5jbSB9utAUZJWO HN2cqzpWXnU75JqXhOgYlLE9ZJRamcAaclfcHstjmVDZbuw16tBh87CAs5/MXlphlYI5h4aUD5kSk 8nKhRxch9C3SEmvycowp4TYO/tx0fwagGlyK8vHrCKQKHtqmsOUDrL5bHSWakl4DH5o0Af+2lhmnC +HthWtndQFxyDwrwkF4DrFjIu9jhy7Vf+Dkcy0wdBlpJHwnWAMg+wVZYJVt3nseVpW0oK7GLpp0Mj RV4w1e8m4z+2E5jjn4LUvA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPmi4-0006Pr-DS; Wed, 08 Feb 2023 10:50:16 -0500 In-Reply-To: <05087da5-30d3-dbb5-1dd7-70acf050b37d@yandex.ru> (message from Dmitry Gutov on Wed, 8 Feb 2023 17:16:40 +0200) 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:255150 Archived-At: > Date: Wed, 8 Feb 2023 17:16:40 +0200 > Cc: 61361@debbugs.gnu.org > From: Dmitry Gutov > > On 08/02/2023 17:09, Eli Zaretskii wrote: > >> From: Xinyang Chen > >> Date: Wed, 8 Feb 2023 09:25:07 -0500 > >> > > But the 'cursor' property just supplies the index in the display > > string where your Lisp program wants to place the cursor. Emacs > > cannot place point inside a display string. So the display engine > > needs to find where that index is on display. And it cannot find that > > place because there's no glyph that corresponds to the newline. > > So, no chance of the display engine detecting that the same display > string with the 'cursor' property has a newline at that position? "No chance" is too strong: this is software, after all. But it's not easy to do that. It involves several places with tricky code, that currently all work in unison, and make the same assumptions: . the decision where to place the cursor works on a screen-line basis: as we perform layout of each screen line, we decide whether the cursor should be in that line, and if so, on what glyph of that line . the decision whether a screen line is a candidate for showing the cursor when that screen line ends in a newline from a display or an overlay string, and/or when there's a gap in buffer positions shown on the screen due to buffer text hidden by some feature . the tricky (to say the least) code which finds the glyph where to put the cursor on a given screen line when buffer positions change non-monotonically with screen positions (due to bidirectional text) and/or have gaps due to overlay and display strings (it is here that the 'cursor' property is implemented) Historically, the 'cursor' property is a relatively late addition to the display engine, it was added in Emacs 22.1. It complicated the display code a little, but then along came bidirectional display and complicated that _a_lot_. So we are now at a place where the original design of the Emacs 21 display never meant to be. The entire design of overlay string display is problematic for adding significant features, because when an overlay string is rendered, we lose too much information about the original overlay (e.g., we don't even record where in the buffer the overlay was positioned, nor the overlay from which the string came). So any feature that needs to support properties of overlay strings must actually go back to buffer text and look up the overlays there to find the one we want! > That's unfortunate: that means we'll need to create some wonky > workaround for displaying a completion preview (in Company) when a > completion starts with a newline. Yes, I know. If someone wants to work on lifting this limitation, I can offer help, but I don't think I'll have time (nor motivation, to say the truth) to work on this myself.