From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#61361: cursor cannot be at the start of overlay that starts with a newline Date: Thu, 9 Feb 2023 00:06:17 +0200 Message-ID: <58199b3a-c4e4-ccf9-a9a2-febdcdbcc1f0@yandex.ru> References: <83o7q4nw2s.fsf@gnu.org> <83k00snqhp.fsf@gnu.org> <05087da5-30d3-dbb5-1dd7-70acf050b37d@yandex.ru> <83h6vwnol6.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="17993"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: chenxy@mit.edu, 61361@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 08 23:07:15 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 1pPsax-0004Rc-2y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Feb 2023 23:07:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPsam-0004BL-Ug; Wed, 08 Feb 2023 17:07:04 -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 1pPsak-0004Ar-Ht for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 17:07: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 1pPsak-0001MX-9m for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 17:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pPsaj-0005hJ-Rr for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 17:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Feb 2023 22:07: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.167589398921860 (code B ref 61361); Wed, 08 Feb 2023 22:07:01 +0000 Original-Received: (at 61361) by debbugs.gnu.org; 8 Feb 2023 22:06:29 +0000 Original-Received: from localhost ([127.0.0.1]:56826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPsaC-0005gW-RM for submit@debbugs.gnu.org; Wed, 08 Feb 2023 17:06:29 -0500 Original-Received: from mail-ej1-f42.google.com ([209.85.218.42]:42694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPsaA-0005gF-HI for 61361@debbugs.gnu.org; Wed, 08 Feb 2023 17:06:27 -0500 Original-Received: by mail-ej1-f42.google.com with SMTP id sa10so1006820ejc.9 for <61361@debbugs.gnu.org>; Wed, 08 Feb 2023 14:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=RbbsTuIWFULKsztJSlf5JZS1pmspEvoOnsNGZvh3Ru4=; b=C4et48kRB5ScVaHc0J8deAzrfW9Xkjro9YoJA6/TOfNk96cEY0zi0y2xJDDVJpDHs5 FMvgBdDoqkwpf1Rajz2zhcxPF1lFAxtWEmsIKt2r6/hG69ti4teSUSIQT4NjjyhMFbp6 qO+phlK035w6dH6fyxf10LlpbXgfKg374K12sf3Us9BYywcVoMlM1EO8vSwqaa+FldQV 61OeUe6YHLMSUfwSn/hwwsSsHvY6QsMlhtxuJQHjteDnB6OyaI4ZczYwBNHQIMVCzEU4 OBSrwabByarClFnd1LsjuoysLNWc4OBB817yGA6KMB63uLdOzRNgMijMFtYJoKW7CvSb Grog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RbbsTuIWFULKsztJSlf5JZS1pmspEvoOnsNGZvh3Ru4=; b=b+Pm2lti5OJBR+kUm7bQp4xGJRMTpAuRR1MAkqmkoSIRKbSTI5ay8JrgKMNxevk3VE Rg6ctMqBIVD4qlpw+W7Z3bH/vvbkr4L8pau9nGPMGst1WndL0/gN9wvE00UhMawZ+9st V0G3+HwEZUU2nxsstswHe7CZPe9eOMO1Rp1Zqv1hGrDYNqZrTCFCAqeju8wmXanRZw/7 kfZHweCzFSE46vCnAIWSJOqD+R8JIMGdqW4nPx2r8Mesu75KVXli3QZoSB033HWTa9fb /XWJagpXXUNGLsft8S1kOJPHBnXkWE+oh9m6+Rkkf9tKo1UKZpNcMYxMO7uD7PCUINoJ 666w== X-Gm-Message-State: AO0yUKVMYMc2RJYhvUZl3+1XG/Q7rbPWdnmxNZ+Vc+odsT/OlE4dINTx 5aQyMz79eU83yaSVJQ3YrKA= X-Google-Smtp-Source: AK7set9jFxiR9AM4dta+3gTenTytewTdZ8yM9YrQqwr/EgAoaeFPlcHCPgDTAU1UlQxG7WOwLSH2Mw== X-Received: by 2002:a17:906:5a5e:b0:8ae:11ca:81de with SMTP id my30-20020a1709065a5e00b008ae11ca81demr3292333ejc.34.1675893980254; Wed, 08 Feb 2023 14:06:20 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id gc1-20020a1709072b0100b008a58c3b8daesm4229ejc.164.2023.02.08.14.06.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Feb 2023 14:06:19 -0800 (PST) Content-Language: en-US In-Reply-To: <83h6vwnol6.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:255165 Archived-At: On 08/02/2023 17:50, Eli Zaretskii wrote: >> 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. Thank you for the description. I might try that someday, but definitely not in the near term. Maybe someone beats me to it. Hopefully.