From unknown Tue Jun 17 20:18:56 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#77438 <77438@debbugs.gnu.org> To: bug#77438 <77438@debbugs.gnu.org> Subject: Status: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer (=?UTF-8?Q?Vim=E2=80=99s?= virtualedit=all Equivalent in Emacs) Reply-To: bug#77438 <77438@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:18:56 +0000 retitle 77438 [FEATURE REQUEST] Freely positioning the cursor anywhere in t= he buffer (Vim=E2=80=99s virtualedit=3Dall Equivalent in Emacs) reassign 77438 emacs submitter 77438 James Cherti severity 77438 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 16:02:54 2025 Received: (at submit) by debbugs.gnu.org; 1 Apr 2025 20:02:54 +0000 Received: from localhost ([127.0.0.1]:51500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzhp0-0007Tk-84 for submit@debbugs.gnu.org; Tue, 01 Apr 2025 16:02:54 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33020) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzhox-0007Sc-9Z for submit@debbugs.gnu.org; Tue, 01 Apr 2025 16:02:51 -0400 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 1tzhor-00051P-Dq for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2025 16:02:45 -0400 Received: from bee.birch.relay.mailchannels.net ([23.83.209.14]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzhop-0005iU-8A for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2025 16:02:45 -0400 X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E3A492C3604 for ; Tue, 1 Apr 2025 20:02:40 +0000 (UTC) Received: from pdx1-sub0-mail-a251.dreamhost.com (100-122-87-32.trex-nlb.outbound.svc.cluster.local [100.122.87.32]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6C31C2C449B for ; Tue, 1 Apr 2025 20:02:40 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1743537760; a=rsa-sha256; cv=none; b=9nwHHgJvqBIqNQGJq5Vz6HHOjrB4+Yl/EVLNPt5TviL9VcuRDfSc2K9QEftzF7+6IbTYSL Q6HnzSG1BBdi2wP57uBq3NqkftiGg018Uo4xDAzdCCRIrAVCpDeB62gOeUHTC2ReHc3uwq 9qlYj8ji0pc/CIuEtqGJ4VYmwmEBNniLKKrDjImb2ClH3IvG6Ge5B2HeyoQlh4EdtR4Ay9 bLR9JM5MjgDETDrmSU5egPSyGuRiA+ZPpVEnOoC1IjYNE8WxvbHEIL4/XczKwmmXhZNqOG QN1ubaoZ0nn6oJegrO+VbzYq/bpSGjIpH+1qvv9u3u9Z2zitWVfm9/jX+XqaBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1743537760; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=vQSXLlt4aF/wPfhpQMGThP1o8i+txOykfepasvdNVlo=; b=Mn8YWCQSZGah3xsOH9imDNCj4ilS3xeZlNCpP5fy+uhlvPgstangSiY/VyC0b+G2/9bk6F 78P+B0WLBC2G+o4I9VNo0wa/hPb0UdvxR6/86etPlyWOzIAWiiwrZRdvJKJP3bDghzgx/d IzJBOiwLVvymTiCMkrNT7mP8wdgQ68Ktqha81yW6hAjTVo95upYXSiH5FyJeHiPf9bFVbr pTnWLuw/D45BnjHNHm98eHvLdRFwyTeWJ1dmR3NcFFfR8iFwP/vEGobs8dd+xQasyqw3v9 XOn6ynn/Oe8aDxBStp7W2rd3nwPwSEPMrPvv0u5TS5FFRsKnflSlmFcMwW3K9g== ARC-Authentication-Results: i=1; rspamd-7668cf9b8d-w96rx; auth=pass smtp.auth=dreamhost smtp.mailfrom=contact@jamescherti.com X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|contact@jamescherti.com X-MailChannels-Auth-Id: dreamhost X-Troubled-Eight: 37461ef80809d1e6_1743537760655_226437529 X-MC-Loop-Signature: 1743537760655:186051530 X-MC-Ingress-Time: 1743537760654 Received: from pdx1-sub0-mail-a251.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.122.87.32 (trex/7.0.3); Tue, 01 Apr 2025 20:02:40 +0000 Received: from [192.168.5.23] (24-212-139-93.cable.teksavvy.com [24.212.139.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: contact@jamescherti.com) by pdx1-sub0-mail-a251.dreamhost.com (Postfix) with ESMTPSA id 4ZRzSJ14VRz2W for ; Tue, 1 Apr 2025 13:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamescherti.com; s=dreamhost; t=1743537760; bh=vQSXLlt4aF/wPfhpQMGThP1o8i+txOykfepasvdNVlo=; h=Date:To:From:Subject:Content-Type:Content-Transfer-Encoding; b=LGZ1ZTBZERwhEHCcQwV7xnhuicMcrZrKGtcTNw7xeg7iOywohmysOljmHsZ+Ndf0R 4jZvG+du5+IG4MIoE0Mugk3wz6m753hXSFMtIuks33QpZ1H8VGAbYQ+4mLDS7qQYqP OIp53EfkxHt+2rQosljAdXs8OmutKonL3It+oW4OYBsM/NLrU7wzlpyuQTNh8OGTIO 01N/eSXOvuIJZKNweV1b70XIDJlHjlaFB0txHWbbUywRd7VmeORWsR5XyUsHwT+fKx ZQK2zhYu/gderWS19RF2Jct+CTD4lrv5aN4qisV8xkntBqR+5pLyGP3rzo/hpqw0OZ cuCEMarNyHdxg== Message-ID: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> Date: Tue, 1 Apr 2025 16:02:39 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: bug-gnu-emacs@gnu.org From: James Cherti Subject: =?UTF-8?Q?=5BFEATURE_REQUEST=5D_Freely_positioning_the_cursor_anywh?= =?UTF-8?Q?ere_in_the_buffer_=28Vim=E2=80=99s_virtualedit=3Dall_Equivalent_i?= =?UTF-8?Q?n_Emacs=29?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=23.83.209.14; envelope-from=contact@jamescherti.com; helo=bee.birch.relay.mailchannels.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, Implementing an Emacs equivalent of Vim's `set virtualedit=all` feature would be interesting, especially for editing indentation-sensitive file types like YAML or Python. In Vim, the `set virtualedit=all` setting allows the cursor to move freely to any position in the text, even beyond the end of lines and after the last line of the file. This differs from the default behavior, where the cursor is constrained to valid text positions. Unlike Vim's `virtualedit=all` mode, Emacs' quarter-plane, picture-mode, and artist-mode packages insert actual spaces into the buffer. In contrast, Vim’s `set virtualedit=all` allows the cursor to be placed in positions where no text exists, but real spaces are not added until a character is typed. This distinction is important because, in `virtualedit=all`, the absence of real spaces ensures that the undo/redo history remains unaffected by cursor movements alone. -- James Cherti GitHub: https://github.com/jamescherti Website: https://www.jamescherti.com/ From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 07:40:02 2025 Received: (at 77438) by debbugs.gnu.org; 2 Apr 2025 11:40:02 +0000 Received: from localhost ([127.0.0.1]:55577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzwRt-0002ij-BY for submit@debbugs.gnu.org; Wed, 02 Apr 2025 07:40:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34344) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzwRr-0002ho-B0 for 77438@debbugs.gnu.org; Wed, 02 Apr 2025 07:40:00 -0400 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 1tzwRl-0002Xi-W3; Wed, 02 Apr 2025 07:39:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=SzqJCiBci/J+zyjURwp+ysyfxRQLNrkW5Zy1AoUSG6k=; b=GkjKOJj2OnqUYp5IoQoK Sn6f7X9lKOL3QJjr7pb40HUyc2kMdt3fN2c/fkrdwPLELWXM1IZyJANL/uVXNLMvuFwTwvnkL52R4 qoROuegKiRj0TeDOxSazphjPdznIgO8AQmHssXBburaRE0bAakVOTzx2ZLn6bZlTKoNpTOadI6vMx fPGCh+N4ofl1aE1kL5MsGLbjHAvatXmvR96gIWiZ3D5UkQeGpRX8N/NaAbIsb6Y9V2HSfDGbozNXq f2xKlR/STgTswjP/arNmnG1VlHkhdwLwC1D1Ysu5NBk7caVa5R/Ka923SpWuvcHL8/KI7p+3MHVQT fquSK5qkcujR1A==; Date: Wed, 02 Apr 2025 14:39:50 +0300 Message-Id: <86wmc223nd.fsf@gnu.org> From: Eli Zaretskii To: James Cherti In-Reply-To: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> (message from James Cherti on Tue, 1 Apr 2025 16:02:39 -0400) Subject: Re: bug#77438: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer =?utf-8?Q?=28Vim=E2=80=99s?= virtualedit=all Equivalent in Emacs) References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77438 Cc: 77438@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 1 Apr 2025 16:02:39 -0400 > From: James Cherti > > Implementing an Emacs equivalent of Vim's `set virtualedit=all` > feature would be interesting, especially for editing > indentation-sensitive file types like YAML or Python. > > In Vim, the `set virtualedit=all` setting allows the cursor to move > freely to any position in the text, even beyond the end of lines and > after the last line of the file. This differs from the default > behavior, where the cursor is constrained to valid text positions. > > Unlike Vim's `virtualedit=all` mode, Emacs' quarter-plane, > picture-mode, and artist-mode packages insert actual spaces into the > buffer. In contrast, Vim’s `set virtualedit=all` allows the cursor to > be placed in positions where no text exists, but real spaces are not > added until a character is typed. > > This distinction is important because, in `virtualedit=all`, the > absence of real spaces ensures that the undo/redo history remains > unaffected by cursor movements alone. Can't one do this using overlays instead of inserting spaces? But eventually, you'd need to insert spaces, if you actually type something wherever you move cursor. So maybe an easier way is to use picture-mode after forcing undo to not record some commands for a period. (Not that I understand why not touching the undo history is such a big deal.) From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 09:02:20 2025 Received: (at submit) by debbugs.gnu.org; 2 Apr 2025 13:02:20 +0000 Received: from localhost ([127.0.0.1]:56076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzxjY-0008Bi-0Y for submit@debbugs.gnu.org; Wed, 02 Apr 2025 09:02:20 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52404) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzxjV-0008Ai-OQ for submit@debbugs.gnu.org; Wed, 02 Apr 2025 09:02:18 -0400 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 1tzxjP-0007yl-Oi for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2025 09:02:11 -0400 Received: from dwarf.ash.relay.mailchannels.net ([23.83.222.53]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzxjN-0003Fu-Aj; Wed, 02 Apr 2025 09:02:11 -0400 X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 764358A5395; Wed, 2 Apr 2025 13:02:06 +0000 (UTC) Received: from pdx1-sub0-mail-a266.dreamhost.com (trex-5.trex.outbound.svc.cluster.local [100.96.205.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id F13818A495D; Wed, 2 Apr 2025 13:02:05 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1743598926; a=rsa-sha256; cv=none; b=F0KBqi4WG+81C74FZA6/hVaE9FJW19SlU4XqVhtJS1lTj/n/1Y2zKQvnhxHYcoEAveogaN zrXWfegdhi9EP5rfzOP4PJcg2WauwkYy6nQGseM93cLtTerD4O4JKBYIqCx/tnQr/h53xy FhhQBFp5vBUZ4rZaFv2B7syZFt5z41rwMuTstKPeFRrC+hQNMf9ZwbbhQ8SzrwBgJIZApG AIdM4g1ddBPkOsJm1UBM+JOtV0xZlaor91L2R9Rp0YWto7TBgTlGcdpo9p4evmu+qVj8KF 2A4921xiaDxkfdElr7Ph4IzWkvhCyT/0hGsLTInX3QGbvIFZ/YvLZ3jwUNFF5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1743598926; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=09lyH4JSVS1MiyQ+VvYymyxd8BE0dXZN81wyr9QxQV8=; b=pogH2uRjSJk1a+reeggaKzrSFIqv5tLbEx6P2IYuLTx0UGY9oXczzs+5BMvqYIurdt5B3d JtWuMFxbjg1A7iT3DhPNnHDDn97mjNqfD/YE/oDjaKqk+jIf6KtXSbokEwsTA+SFDicw7U xuoSgCdinVKMKjDgaiy6yKiz5ksS2F28TXhPgHWevNxuO8+7CEPFJiaTZUScO+E4sBCclw ldVKO63SYjOqETRlT0h8DWrEH4a/6FPJ43byK5AwrsCA1FnoN52hMX3DzbZ9hXyb+wPKGu 7l99AhqxTatxVpfuyYNqUxlXIZE6wfDxEu94rIKTPHO9XZh70a/S2sW6djgKIw== ARC-Authentication-Results: i=1; rspamd-85757496c5-t29j8; auth=pass smtp.auth=dreamhost smtp.mailfrom=contact@jamescherti.com X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|contact@jamescherti.com X-MailChannels-Auth-Id: dreamhost X-Power-Drop: 764ff6b71b52fdbb_1743598926207_3723889641 X-MC-Loop-Signature: 1743598926207:2820717057 X-MC-Ingress-Time: 1743598926206 Received: from pdx1-sub0-mail-a266.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.205.60 (trex/7.0.3); Wed, 02 Apr 2025 13:02:06 +0000 Received: from [192.168.5.23] (24-212-139-93.cable.teksavvy.com [24.212.139.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: contact@jamescherti.com) by pdx1-sub0-mail-a266.dreamhost.com (Postfix) with ESMTPSA id 4ZSQ4Y49sqz1Z; Wed, 2 Apr 2025 06:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamescherti.com; s=dreamhost; t=1743598925; bh=09lyH4JSVS1MiyQ+VvYymyxd8BE0dXZN81wyr9QxQV8=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=DVrV+PfZIldY6GqznEm4K12O7F1JWZsVz9tcDEHan2cK9iiUuZhM8SVHTi2/sbx5K dgTPvGEziRtSjm6wFzWB9hYTxsxuknLrTpFfMBKAszIT1TzoEBAq0wriTfO6MIOy8T Y0XtpVCZXOEp6UYzCHIp/BTvhPp0474tCBZlhGrQZqU2+rHubtqk907HYofRSxZOUA K5LR05cUrA3+w+eG7/No8CE22lg4fj+IGNpQFQCHNIHfMrcdpa8Xti1KLOyFU8zlYM PaFkgzWu0db2K2c3gPMa3e1V0jjcJVnKSoEnJFdXVDI4NRORbx7AjItEzf9LowOELX 0Pfal5i7rSs5Q== Message-ID: Date: Wed, 2 Apr 2025 09:02:04 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_bug=2377438=3A_=5BFEATURE_REQUEST=5D_Freely_positio?= =?UTF-8?Q?ning_the_cursor_anywhere_in_the_buffer_=28Vim=E2=80=99s_virtualed?= =?UTF-8?Q?it=3Dall_Equivalent_in_Emacs=29?= To: bug-gnu-emacs@gnu.org, Eli Zaretskii References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <86wmc223nd.fsf@gnu.org> Content-Language: en-US From: James Cherti In-Reply-To: <86wmc223nd.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=23.83.222.53; envelope-from=contact@jamescherti.com; helo=dwarf.ash.relay.mailchannels.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello Eli, On 2025-04-02 07:39, Eli Zaretskii wrote: >> Date: Tue, 1 Apr 2025 16:02:39 -0400 >> From: James Cherti >> >> Implementing an Emacs equivalent of Vim's `set virtualedit=all` >> feature would be interesting, especially for editing >> indentation-sensitive file types like YAML or Python. >> >> In Vim, the `set virtualedit=all` setting allows the cursor to move >> freely to any position in the text, even beyond the end of lines and >> after the last line of the file. This differs from the default >> behavior, where the cursor is constrained to valid text positions. >> >> Unlike Vim's `virtualedit=all` mode, Emacs' quarter-plane, >> picture-mode, and artist-mode packages insert actual spaces into the >> buffer. In contrast, Vim’s `set virtualedit=all` allows the cursor to >> be placed in positions where no text exists, but real spaces are not >> added until a character is typed. >> >> This distinction is important because, in `virtualedit=all`, the >> absence of real spaces ensures that the undo/redo history remains >> unaffected by cursor movements alone. > > Can't one do this using overlays instead of inserting spaces? I previously attempted to implement this behavior using overlays, but I encountered an issue: when adding virtual spaces with overlays, Emacs still treated all the added spaces as a single space for movement and alignment purposes. This made precise cursor positioning difficult, as the cursor did not behave as expected when navigating or attempting to place text at arbitrary positions. > But eventually, you'd need to insert spaces, if you actually type > something wherever you move cursor. So maybe an easier way is to use > picture-mode after forcing undo to not record some commands for a > period. (Not that I understand why not touching the undo history is > such a big deal.) One of the purposes of this bug report is to explore the possibility of implementing a feature in Emacs that allows positioning the cursor anywhere within the buffer. This would benefit not only modes like picture-mode, but also indentation-sensitive modes such as Python and YAML. Not recording cursor movement in the undo history is advantageous because it prevents unnecessary undo entries from being created. This helps keep the undo tree clean and ensures that reverting meaningful edits remains efficient and straightforward. For example: - Modify line 10 (change 1). - Move the cursor down 10 times. - Modify line 21 (change 2). If undo records every cursor movement due to spaces being added multiple times, reverting to "change 1" would require 12 undo steps instead of just two, making the process inefficient. -- James Cherti GitHub: https://github.com/jamescherti Website: https://www.jamescherti.com/ From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 09:25:44 2025 Received: (at 77438) by debbugs.gnu.org; 2 Apr 2025 13:25:45 +0000 Received: from localhost ([127.0.0.1]:56152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzy6A-0002OS-9i for submit@debbugs.gnu.org; Wed, 02 Apr 2025 09:25:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41940) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzy65-0002Hy-B8 for 77438@debbugs.gnu.org; Wed, 02 Apr 2025 09:25:39 -0400 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 1tzy5z-00026z-KI; Wed, 02 Apr 2025 09:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Js8W9X4dJokB6O0nkS3rn9PFCGfTGcNKHg/CdVHMzfQ=; b=N1q9z6M4OLNtxnnAcNUY UuDdBBcSNLmxJOL+LrIChC+A0+ccrjWorAVRFqJgY/vtbiOP/l9OPlO1BZzJuX4hS3N74sagPo1ia +PYZjUyhqJfKH5q0mbi5OvG4Y1PP52YOo7n+06QIL9rAA2D/uhxW6VxUFbjW4IqYmsFn3vmZy2Oak 5o5V+m/CknmIq1x32mPMz4vNt8d2ptXR0852sdRvcc8f/eZqgGo655lK95qQ/CPf/Uuq5vTOfrDRW NL+O1U58QPaP5FqPAZcnJ0WP1ieZFrtrXzMzZTI4dqWoHiJAFJxH0+7Q4oG2lemsQ1t9gKvTOBxEy M8SOEbYB6NAkdg==; Date: Wed, 02 Apr 2025 16:25:28 +0300 Message-Id: <86ldsi1yrb.fsf@gnu.org> From: Eli Zaretskii To: James Cherti In-Reply-To: (message from James Cherti on Wed, 2 Apr 2025 09:02:04 -0400) Subject: Re: bug#77438: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer =?utf-8?Q?=28Vim=E2=80=99s?= virtualedit=all Equivalent in Emacs) References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <86wmc223nd.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77438 Cc: 77438@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 2 Apr 2025 09:02:04 -0400 > From: James Cherti > > >> This distinction is important because, in `virtualedit=all`, the > >> absence of real spaces ensures that the undo/redo history remains > >> unaffected by cursor movements alone. > > > > Can't one do this using overlays instead of inserting spaces? > > I previously attempted to implement this behavior using overlays, but > I encountered an issue: when adding virtual spaces with overlays, > Emacs still treated all the added spaces as a single space for > movement and alignment purposes. This made precise cursor positioning > difficult, as the cursor did not behave as expected when navigating or > attempting to place text at arbitrary positions. You could either replace the overlay on each cursor motion command, or set the 'cursor' property of the overlay string to tell Emacs where to place the cursor, and move that property with each cursor motion command. > > But eventually, you'd need to insert spaces, if you actually type > > something wherever you move cursor. So maybe an easier way is to use > > picture-mode after forcing undo to not record some commands for a > > period. (Not that I understand why not touching the undo history is > > such a big deal.) > > One of the purposes of this bug report is to explore the possibility > of implementing a feature in Emacs that allows positioning the cursor > anywhere within the buffer. This would benefit not only modes like > picture-mode, but also indentation-sensitive modes such as Python > and YAML. I'm not sure I understand how this is related to indentation-sensitive modes. Can you tell more? > Not recording cursor movement in the undo history is advantageous > because it prevents unnecessary undo entries from being created. This > helps keep the undo tree clean and ensures that reverting meaningful > edits remains efficient and straightforward. Emacs normally records cursor motion commands in the undo list, so I'm not sure I understand why undo revert commands that are not just buffer text modifications would be annoying enough to justify the complicated implementation you'd need to use overlays. > For example: > - Modify line 10 (change 1). > - Move the cursor down 10 times. > - Modify line 21 (change 2). > > If undo records every cursor movement due to spaces being added > multiple times, reverting to "change 1" would require 12 undo > steps instead of just two, making the process inefficient. Yes, but this happens also in normal editing, doesn't it? From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 11:22:42 2025 Received: (at submit) by debbugs.gnu.org; 2 Apr 2025 15:22:42 +0000 Received: from localhost ([127.0.0.1]:58996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzzvN-00018N-Bi for submit@debbugs.gnu.org; Wed, 02 Apr 2025 11:22:41 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45178) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzzvL-00017b-8v for submit@debbugs.gnu.org; Wed, 02 Apr 2025 11:22:40 -0400 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 1tzzvE-0002BP-6k for bug-gnu-emacs@gnu.org; Wed, 02 Apr 2025 11:22:32 -0400 Received: from fuchsia.ash.relay.mailchannels.net ([23.83.222.64]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzzv9-0001Yw-0E; Wed, 02 Apr 2025 11:22:28 -0400 X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6F0B1C4725; Wed, 2 Apr 2025 15:22:22 +0000 (UTC) Received: from pdx1-sub0-mail-a208.dreamhost.com (trex-6.trex.outbound.svc.cluster.local [100.97.44.91]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 338521C402B; Wed, 2 Apr 2025 15:22:22 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1743607342; a=rsa-sha256; cv=none; b=eSmOLFvxsn9LI3Ten5EpJX3ZE5rJNPyJZRp4aqEuufeJyWzjFm58PKg8Vc6J7I0SWaxfCL dBhKYzPkp/ykciXpCFh8SLcZs7XXBiqQtPyf7JOvMeOoOYNXGehLK8bv2Ojg+jsV9ybB5r UdD0lsO7IuqKGjp1VpHzuUJcCcJBhiJ2s90AG6M4Qgq3uVuNTR4FesJB7jsWkmscVCU6cJ crBzKuet+nl74a49CRd41t17TiIzsJX5J+3NoY+f4koD6k1Dv3DYABPGXLBzjXYoEZtBjd GgRdhReuRJlLYQ0Rd2LhrXsnL62D9cOYEOJtU6Gaoa3YvM0O7SRpZYjwDpVR6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1743607342; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kLZdt2N7Yenp9/3byn2QPHSy2iVq1tXtMJb4iileeas=; b=oupgFygDDrUFfsGl76ONqMk9IVGf2JxJYtv+/UQnbHpnwLtekYymhtRLd+ZBV1u3pPXjF2 zbEzPTY8zI1+Lnu0hTqIkBK2BrCdxgsEKgGj+erLH6rZmfaLVEBRVM+YaPjjzYwwNQtYu0 i0WM9tFI2WYNmZpD2G6Jl4pNcS0HzqX4dYL1vrAzaR4On51h+ayVKheaUnL/S7KkpfXldv uxj/0kqMhJRlPSssNkLc/RqMl73c260LYy821SAPKlfrrkFe0tk+9rMzEI9rNJfzXYxPzx WyP0ICGf0HwAPZUENys3mbxa+PFY+6KG/qHJsjNWWXOkf5eojJZMSu9KX6pPMw== ARC-Authentication-Results: i=1; rspamd-7668cf9b8d-td8xv; auth=pass smtp.auth=dreamhost smtp.mailfrom=contact@jamescherti.com X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|contact@jamescherti.com X-MailChannels-Auth-Id: dreamhost X-Bitter-Illegal: 7ac823710a097527_1743607342518_100410604 X-MC-Loop-Signature: 1743607342518:2845550088 X-MC-Ingress-Time: 1743607342518 Received: from pdx1-sub0-mail-a208.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.97.44.91 (trex/7.0.3); Wed, 02 Apr 2025 15:22:22 +0000 Received: from [192.168.5.23] (24-212-139-93.cable.teksavvy.com [24.212.139.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: contact@jamescherti.com) by pdx1-sub0-mail-a208.dreamhost.com (Postfix) with ESMTPSA id 4ZSTBP67nTzJW; Wed, 2 Apr 2025 08:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamescherti.com; s=dreamhost; t=1743607342; bh=kLZdt2N7Yenp9/3byn2QPHSy2iVq1tXtMJb4iileeas=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=YXfUH5vObPLF1J9vkqkszs9aXocNnp+5gB1cu85Mxcqr6dvoLHsJfDttVovTU1T9D 458v3ffUpMVg4xr44xiiQ3B+ANsWnIcrC1P0qel9zvPBELHfwbFxdAAfyiPs5xi/du MS2dUuZhN3oefu87PfO7wLr9YGU7RAO8o6sX2+YQiOU9rF7C0mzIjZy08EqBO/ucbX 2ohc0/Jv8ZCIAXUT46sA9sBMJSGcZS3ljcf1Wmm+QTYxb59i1zE0RgiF5eIwmFwk0P mIGBpKB4CvZWEZA/AlQYFnVK7mOInSa9aOg/8pKtR3/Gfz+IUSyzQlaGe/efyfRjwL qXc+HhgQZURPA== Message-ID: Date: Wed, 2 Apr 2025 11:22:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_bug=2377438=3A_=5BFEATURE_REQUEST=5D_Freely_positio?= =?UTF-8?Q?ning_the_cursor_anywhere_in_the_buffer_=28Vim=E2=80=99s_virtualed?= =?UTF-8?Q?it=3Dall_Equivalent_in_Emacs=29?= To: bug-gnu-emacs@gnu.org, Eli Zaretskii References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <86wmc223nd.fsf@gnu.org> <86ldsi1yrb.fsf@gnu.org> Content-Language: en-US From: James Cherti In-Reply-To: <86ldsi1yrb.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=23.83.222.64; envelope-from=contact@jamescherti.com; helo=fuchsia.ash.relay.mailchannels.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 2025-04-02 09:25, Eli Zaretskii wrote: >> Date: Wed, 2 Apr 2025 09:02:04 -0400 >> From: James Cherti >> >>>> This distinction is important because, in `virtualedit=all`, the >>>> absence of real spaces ensures that the undo/redo history remains >>>> unaffected by cursor movements alone. >>> >>> Can't one do this using overlays instead of inserting spaces? >> >> I previously attempted to implement this behavior using overlays, but >> I encountered an issue: when adding virtual spaces with overlays, >> Emacs still treated all the added spaces as a single space for >> movement and alignment purposes. This made precise cursor positioning >> difficult, as the cursor did not behave as expected when navigating or >> attempting to place text at arbitrary positions. > > You could either replace the overlay on each cursor motion command, or > set the 'cursor' property of the overlay string to tell Emacs where to > place the cursor, and move that property with each cursor motion > command. > >>> But eventually, you'd need to insert spaces, if you actually type >>> something wherever you move cursor. So maybe an easier way is to use >>> picture-mode after forcing undo to not record some commands for a >>> period. (Not that I understand why not touching the undo history is >>> such a big deal.) >> >> One of the purposes of this bug report is to explore the possibility >> of implementing a feature in Emacs that allows positioning the cursor >> anywhere within the buffer. This would benefit not only modes like >> picture-mode, but also indentation-sensitive modes such as Python >> and YAML. > > I'm not sure I understand how this is related to indentation-sensitive > modes. Can you tell more? When navigating up or down, a cursor that shifts left or right due to varying line lengths can be visually distracting and disrupt the editing flow. Keeping the cursor in a fixed column ensures a straight-line movement, making it easier to track its position and maintain indentation accuracy. >> Not recording cursor movement in the undo history is advantageous >> because it prevents unnecessary undo entries from being created. This >> helps keep the undo tree clean and ensures that reverting meaningful >> edits remains efficient and straightforward. > > Emacs normally records cursor motion commands in the undo list, so I'm > not sure I understand why undo revert commands that are not just > buffer text modifications would be annoying enough to justify the > complicated implementation you'd need to use overlays. > >> For example: >> - Modify line 10 (change 1). >> - Move the cursor down 10 times. >> - Modify line 21 (change 2). >> >> If undo records every cursor movement due to spaces being added >> multiple times, reverting to "change 1" would require 12 undo >> steps instead of just two, making the process inefficient. > > Yes, but this happens also in normal editing, doesn't it? In my setup, cursor movement is only included in the undo history when a change is made. I am using evil-mode and undo-fu with the following settings: (setq evil-want-fine-undo t) (setq evil-undo-system 'undo-fu) Here is what happens in this setup: 1. Modify line 10 (change 1). 2. Move the cursor down 10 times. 3. Modify line 21 (change 2). When I press u (undo) the first time, only the change on line 21 is undone. When I press u (undo) again, the change on line 10 is undone. (I don’t need to press u (undo) 10 more times to undo the cursor movement before I can undo the change on line 10.) -- James Cherti GitHub: https://github.com/jamescherti Website: https://www.jamescherti.com/ From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 23:37:06 2025 Received: (at 77438) by debbugs.gnu.org; 3 Apr 2025 03:37:06 +0000 Received: from localhost ([127.0.0.1]:60214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0BO6-0003s1-De for submit@debbugs.gnu.org; Wed, 02 Apr 2025 23:37:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39780) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0BO3-0003rT-NO for 77438@debbugs.gnu.org; Wed, 02 Apr 2025 23:37:04 -0400 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 1u0BNy-0006iZ-4t; Wed, 02 Apr 2025 23:36:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=152k5RlF71l4g5mKl4UPlRdrUPFZK/6T5AsLAzxZgV0=; b=bcBPKWrZusvl mPPVSKgo6Z2ZR1CRL045asQAJ3F3XKqT3VGH5TDQzi8ctzHqf4MYWSVeAoEGtSsAmHXrz5QRqbmUA 4Q/ed5m9HskeCQ5WZPBoD1fcuVD+EIkZApHCvixaMMxuqC5WDp4RhDGqJYx7DavzmdYXVHSHrSUKl vbIYG6TSK3sZmiaUYDLhgr6j7h/VCMd1xpy3LySqwCgm/LxbKi5wbPYDi4Cho9j3fuuMMm/vJ//uO oh/0IO7szqI+Bm6yiVeMbPXLWxPs3C1QpBd+8LDgIofckJTRIqrbAQc/CYSaSkZgZfPQchMB9mEvH h0TfftNJMI5HisJ0cqpG8g==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1u0BNx-000446-7h; Wed, 02 Apr 2025 23:36:57 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: James Cherti In-Reply-To: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> (message from James Cherti on Tue, 1 Apr 2025 16:02:39 -0400) Subject: Re: bug#77438: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer =?iso-8859-1?Q?=28Vim=E2=80=99s?= virtualedit=all Equivalent in Emacs) References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> Message-Id: Date: Wed, 02 Apr 2025 23:36:57 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77438 Cc: 77438@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Unlike Vim's `virtualedit=all` mode, Emacs' quarter-plane, > picture-mode, and artist-mode packages insert actual spaces into the > buffer. In contrast, Vim’s `set virtualedit=all` allows the cursor to > be placed in positions where no text exists, but real spaces are not > added until a character is typed. This won't be exactly easy to do in Emacs. It is fundamental in Emacs that point is on a position between two characters. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 03 11:30:31 2025 Received: (at submit) by debbugs.gnu.org; 3 Apr 2025 15:30:31 +0000 Received: from localhost ([127.0.0.1]:35238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0MWU-0005Wu-Qr for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:30:31 -0400 Received: from lists.gnu.org ([2001:470:142::17]:46096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0MWS-0005Wg-KA for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:30:29 -0400 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 1u0MWM-0002U2-Nt for bug-gnu-emacs@gnu.org; Thu, 03 Apr 2025 11:30:22 -0400 Received: from cheetah.ash.relay.mailchannels.net ([23.83.222.34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u0MWK-0003gT-DH; Thu, 03 Apr 2025 11:30:22 -0400 X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 83DF2782074; Thu, 3 Apr 2025 15:30:14 +0000 (UTC) Received: from pdx1-sub0-mail-a303.dreamhost.com (100-97-44-91.trex-nlb.outbound.svc.cluster.local [100.97.44.91]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 282957842CB; Thu, 3 Apr 2025 15:30:14 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1743694214; a=rsa-sha256; cv=none; b=gS6GNPV2MqIYv84/XJ6eFwbrB3FFnnBDP9U8gk8d0FwXhJvB4hwMSI+zpYB+N6zUw+ipcT g13yN7CwoDGYyQChUBjQLu8KvE8Ju5K6gevRNpgvKPF7732hAZzU5qPYFRguK5b0oMZZbh Vfj50Tj1KigV5/jL09lZ0kBqYnhEkeyEhV99jCxtEQcIQjhSj1VGxwNyKTAtPCGA8UUp19 DYz4BKxcHi7ubQlSwCL0OAQGbvdESeAWlDmGX2/+8uW0gxQk07fEUHAu4VjEzFR9uVI6ZV AbDYnAT28XkHnu2QyfL/qUqnJL2M+nJNVbgETS7bl3QsyMRthr3mxtW0IPx+2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1743694214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vyCFGF6L7QFgIUOBgum0tsTeNKdnAeEP3bPh2PDB/ys=; b=7pYsKaqFFwf7xijzdSQTEZnw/TxKAA7g55Iu7MwO28B0dn68UTNcRmDbLxe4PkzZp14XwF zpiQMctbk7uOaZ4AePvk02cwQrZT+5s6dQ0k7nI9WLjiqYYFelhqwW19JyllqiQDNaXMVn bHUPZN2obGUh/WZSkHWPKBjP7B526TMxzkLgzbIGUG0KMdF3SbPtOmvkqYcBw3/pDdScPJ x3l8oo6Ndw0RvcGrK7FZyRvFzpKt4BznPDdO68yJsdgrVCoqpraQpFoHsLKsDBNxygPmMo MoPcBFcKQ+p9ouWwTux9xJPrKmB1UK8ETXGydyQKMWUqXelUFI65ha9rnM0TAQ== ARC-Authentication-Results: i=1; rspamd-5c8769d675-bz25l; auth=pass smtp.auth=dreamhost smtp.mailfrom=contact@jamescherti.com X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|contact@jamescherti.com X-MailChannels-Auth-Id: dreamhost X-Spicy-Trail: 421e8905535d62d7_1743694214378_1872786520 X-MC-Loop-Signature: 1743694214378:1935392163 X-MC-Ingress-Time: 1743694214378 Received: from pdx1-sub0-mail-a303.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.97.44.91 (trex/7.0.3); Thu, 03 Apr 2025 15:30:14 +0000 Received: from [192.168.5.23] (24-212-139-93.cable.teksavvy.com [24.212.139.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: contact@jamescherti.com) by pdx1-sub0-mail-a303.dreamhost.com (Postfix) with ESMTPSA id 4ZT5K14LgjzWj; Thu, 3 Apr 2025 08:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamescherti.com; s=dreamhost; t=1743694213; bh=vyCFGF6L7QFgIUOBgum0tsTeNKdnAeEP3bPh2PDB/ys=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=Xys0GUFb77fxg+BkLybspo8CjtKy7etLzT/A29dJnPPfuckAEpUhmqNXWp29kuIOd s2sutGUbpHlnHefQPxP2DhK4EVT4eIg9b0ABJ8gToNRXYhzRvB21R00+mu90mwoD3T +9leziM01FTMKhWhuWLuikKCMit215hI0me1sJV5JNBnLzGrAtt0wcdUtN5kGEzwxe 1FoijTj/Wyt4iK5zht1ZAkECzn+W6XRhNTZ8DwcKUC7T9gauGdIOsAr/s54eaMv3cv SJFPjFtZckN4Jn4lTkgtf03x4RvDWJJG5SVftK2y/zYhte5BmjYut3ZLvOkpK7ewNs K+suMAevkabaQ== Message-ID: <5c69553a-e6d6-4303-8800-416f99179f00@jamescherti.com> Date: Thu, 3 Apr 2025 11:30:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_bug=2377438=3A_=5BFEATURE_REQUEST=5D_Freely_positio?= =?UTF-8?Q?ning_the_cursor_anywhere_in_the_buffer_=28Vim=C3=A2s_virtualedit?= =?UTF-8?Q?=3Dall_Equivalent_in_Emacs=29?= To: bug-gnu-emacs@gnu.org, rms@gnu.org References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> Content-Language: en-US From: James Cherti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=23.83.222.34; envelope-from=contact@jamescherti.com; helo=cheetah.ash.relay.mailchannels.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello Richard, On 2025-04-02 23:36, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > Unlike Vim's `virtualedit=all` mode, Emacs' quarter-plane, > > picture-mode, and artist-mode packages insert actual spaces into the > > buffer. In contrast, Vim’s `set virtualedit=all` allows the cursor to > > be placed in positions where no text exists, but real spaces are not > > added until a character is typed. > > This won't be exactly easy to do in Emacs. It is fundamental in Emacs > that point is on a position between two characters. Thank you for taking the time to comment on this feature request, which I hope to see implemented in Emacs. Could this be implemented without modifying the fundamental concept in Emacs that a point is a position between two characters? Here’s an idea: instead of modifying the internal concept where the cursor is equal to the position between two characters, we could implement a new mode that displays a "virtual cursor." This mode would display a cursor representing a specific line/column, rather than a position between two characters. It would allow the cursor to be placed at a line/column position, which may not necessarily be between two characters. > -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU > Project (https://gnu.org) Founder, Free Software Foundation (https:// > fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) -- James Cherti GitHub: https://github.com/jamescherti Website: https://www.jamescherti.com/ From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 03 11:33:16 2025 Received: (at submit) by debbugs.gnu.org; 3 Apr 2025 15:33:16 +0000 Received: from localhost ([127.0.0.1]:35249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0MZA-0005c7-8t for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:33:16 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39264) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0MZ8-0005br-CK for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:33:14 -0400 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 1u0MZ2-0002pa-Ax for bug-gnu-emacs@gnu.org; Thu, 03 Apr 2025 11:33:08 -0400 Received: from tiger.tulip.relay.mailchannels.net ([23.83.218.248]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u0MZ0-000464-9q; Thu, 03 Apr 2025 11:33:08 -0400 X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 34C182C38EF; Thu, 3 Apr 2025 15:33:04 +0000 (UTC) Received: from pdx1-sub0-mail-a303.dreamhost.com (100-99-62-49.trex-nlb.outbound.svc.cluster.local [100.99.62.49]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AF5EC2C485D; Thu, 3 Apr 2025 15:33:03 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1743694383; a=rsa-sha256; cv=none; b=Wi396xocG1mgJ+Gv0evmescjPdG779EQ4HhOI/CxZCGCQUwkAjqT2UL5H5r3ZQXGiFRRdO J2rcW6ZAK5+GWsxxuE5yWyhOPbWqJtjNGpWlqEJO9nz3BHHcQZCkedeZGBs/p0wQdOEFOw tRz2ADZDRIu6X6LZplHvwPCGE2Tli+gGGkY0X67u7+4GFpWeQ8OqfXlLt+faWf6yUuTvee qHeJIMXOjjgPeKUJll2CJAkLDmZKBkpzeZLtynjIw56RTDCQQqJVsy0tIrHLy3GZVndIB6 1JLhZ2TIddoXTyP5d3tumNTFrYNoogCxig/CmH3UBSIPM3lZzdenS8LSfAzmsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1743694383; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2FnPCnaYVqvj5je/ceKecLhUlvu6wbD46gJ+y9G5/DU=; b=xLSZjzFHpYkZa8nnhuZXSXPzCO2FfqrDAuGTIgdHwJI9F/hsrrQqjbjq7aZ2cZUPp6GnYp OANnpa0+Ys1vU/eSpYNMF0dRdiH1iSzUk0CPwj30pn66WnpCrbLIaqur4DHA4i8qJi8Wsw 0jJn6Y1pHPlZfIE1RUfXj6tTbur4SJkEdOMToBHLaSvxfU/+F5+g7HSiT6oWFciU2uCwLW i5CSM8rkfGpPNoEmIQd7ee/ai9NO3bt+KrC8iWubR4knn6JqTRRaM4+S9+jjxYwHdn1Q80 JX+BUzeqeASfBdOQ3MleJejCBpSygfX8aJPkFAEd7GnMolgVmDkTSZ5SHbmtqw== ARC-Authentication-Results: i=1; rspamd-5c8769d675-n6xjz; auth=pass smtp.auth=dreamhost smtp.mailfrom=contact@jamescherti.com X-Sender-Id: dreamhost|x-authsender|contact@jamescherti.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|contact@jamescherti.com X-MailChannels-Auth-Id: dreamhost X-Grain-Little: 21df91e903bad18e_1743694384038_3156404468 X-MC-Loop-Signature: 1743694384038:2124764044 X-MC-Ingress-Time: 1743694384038 Received: from pdx1-sub0-mail-a303.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.62.49 (trex/7.0.3); Thu, 03 Apr 2025 15:33:04 +0000 Received: from [192.168.5.23] (24-212-139-93.cable.teksavvy.com [24.212.139.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: contact@jamescherti.com) by pdx1-sub0-mail-a303.dreamhost.com (Postfix) with ESMTPSA id 4ZT5NH1C0rzRX; Thu, 3 Apr 2025 08:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamescherti.com; s=dreamhost; t=1743694383; bh=2FnPCnaYVqvj5je/ceKecLhUlvu6wbD46gJ+y9G5/DU=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=enY8qgCPp1VLtgBCAYoxzPe0F2MKkbgFKVI58AzJmC0cdQPE3rBlyhEWTZYMLZCDT 4vqRPSQrkGyoC13yuXdl2+R2uOH+wdwNToIJntRNE4ny29j4PhabifO6MfDMsMd230 Zek1wdY0RhU3IfycChLK1kuHiae6hgTijlHYrgheTmxhsacM/IH/YYMDxt58l833bb DEA+dngQP4yeAWkbyNZ3S63XEWnktv2UCHBEPwX5/O16j+VxzZUIBEQopyNsW00ULB 7R+f2rAM2ft+ro7NPYn537Igc69pMg41X+qHTJ8JXceiG4nSAL7zbjU6t+7XXu2Q5V KGt0EDLvhkC/A== Message-ID: <1258e18f-b8ad-4e53-b558-7c21835b3eda@jamescherti.com> Date: Thu, 3 Apr 2025 11:33:02 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_bug=2377438=3A_=5BFEATURE_REQUEST=5D_Freely_positio?= =?UTF-8?Q?ning_the_cursor_anywhere_in_the_buffer_=28Vim=E2=80=99s_virtualed?= =?UTF-8?Q?it=3Dall_Equivalent_in_Emacs=29?= To: bug-gnu-emacs@gnu.org, Eli Zaretskii References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <86wmc223nd.fsf@gnu.org> <86ldsi1yrb.fsf@gnu.org> Content-Language: en-US From: James Cherti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=23.83.218.248; envelope-from=contact@jamescherti.com; helo=tiger.tulip.relay.mailchannels.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello Eli, Thank you for your comments, which helped clarify the purpose of this feature request. If you have any ideas on how this could be implemented, whether or not it involves changing the Emacs internals, please feel free to share your insights. -- James Cherti GitHub: https://github.com/jamescherti Website: https://www.jamescherti.com/ On 2025-04-02 11:22, James Cherti wrote: > On 2025-04-02 09:25, Eli Zaretskii wrote: >>> Date: Wed, 2 Apr 2025 09:02:04 -0400 >>> From: James Cherti >>> >>>>> This distinction is important because, in `virtualedit=all`, the >>>>> absence of real spaces ensures that the undo/redo history remains >>>>> unaffected by cursor movements alone. >>>> >>>> Can't one do this using overlays instead of inserting spaces? >>> >>> I previously attempted to implement this behavior using overlays, but >>> I encountered an issue: when adding virtual spaces with overlays, >>> Emacs still treated all the added spaces as a single space for >>> movement and alignment purposes. This made precise cursor positioning >>> difficult, as the cursor did not behave as expected when navigating or >>> attempting to place text at arbitrary positions. >> >> You could either replace the overlay on each cursor motion command, or >> set the 'cursor' property of the overlay string to tell Emacs where to >> place the cursor, and move that property with each cursor motion >> command. >> >>>> But eventually, you'd need to insert spaces, if you actually type >>>> something wherever you move cursor.  So maybe an easier way is to use >>>> picture-mode after forcing undo to not record some commands for a >>>> period.  (Not that I understand why not touching the undo history is >>>> such a big deal.) >>> >>> One of the purposes of this bug report is to explore the possibility >>> of implementing a feature in Emacs that allows positioning the cursor >>> anywhere within the buffer. This would benefit not only modes like >>> picture-mode, but also indentation-sensitive modes such as Python >>> and YAML. >> >> I'm not sure I understand how this is related to indentation-sensitive >> modes.  Can you tell more? > > When navigating up or down, a cursor that shifts left or right due to > varying line lengths can be visually distracting and disrupt the > editing flow. Keeping the cursor in a fixed column ensures a > straight-line movement, making it easier to track its position and > maintain indentation accuracy. > >>> Not recording cursor movement in the undo history is advantageous >>> because it prevents unnecessary undo entries from being created. This >>> helps keep the undo tree clean and ensures that reverting meaningful >>> edits remains efficient and straightforward. >> >> Emacs normally records cursor motion commands in the undo list, so I'm >> not sure I understand why undo revert commands that are not just >> buffer text modifications would be annoying enough to justify the >> complicated implementation you'd need to use overlays. >> >>> For example: >>> - Modify line 10 (change 1). >>> - Move the cursor down 10 times. >>> - Modify line 21 (change 2). >>> >>> If undo records every cursor movement due to spaces being added >>> multiple times, reverting to "change 1" would require 12 undo >>> steps instead of just two, making the process inefficient. >> >> Yes, but this happens also in normal editing, doesn't it? > > In my setup, cursor movement is only included in the undo history > when a change is made. > > I am using evil-mode and undo-fu with the following settings: > (setq evil-want-fine-undo t) > (setq evil-undo-system 'undo-fu) > > Here is what happens in this setup: > 1. Modify line 10 (change 1). > 2. Move the cursor down 10 times. > 3. Modify line 21 (change 2). > > When I press u (undo) the first time, only the change on line 21 is > undone. > > When I press u (undo) again, the change on line 10 is undone. > > (I don’t need to press u (undo) 10 more times to undo the cursor > movement before I can undo the change on line 10.) > > -- > James Cherti > GitHub: https://github.com/jamescherti > Website: https://www.jamescherti.com/ > > > From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 03 11:49:01 2025 Received: (at submit) by debbugs.gnu.org; 3 Apr 2025 15:49:01 +0000 Received: from localhost ([127.0.0.1]:35298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0MoO-0006KM-Sr for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:49:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35974) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0MoL-0006K0-V0 for submit@debbugs.gnu.org; Thu, 03 Apr 2025 11:48:58 -0400 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 1u0Mo6-0000ui-5c for bug-gnu-emacs@gnu.org; Thu, 03 Apr 2025 11:48:45 -0400 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 1u0Mo5-0007gi-Sy; Thu, 03 Apr 2025 11:48:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=AVMlV3ClTfRqC8mCNUIstO8UEMFbZ/zx//BsUUccOmM=; b=khZixh/0YzsWum8O54x7 1dV89PzRtvBqnUEckndkIy91Nm4kuDNYRUY0/opPb1Sh2I0YLATRKKssh+YfPDyi12f08PAmamFtJ qi6cDcJcQvkSYpnp6o4r/u6midrkXjAbgA3dkd84gRx4HO34yvohgJ56lA21r5EYBw6Fy71W6hpKE SBQzT6mx79YHU3dSOikFXIXYdHXpJ6epbjDzmAbMQ7vArQWYZNmzQNMzpDxcwLoFP3GoMDkB5NSS8 hFcDzPzdIFyZiHDUaEZXtyy6NH1QZ7FSJl4ofqaIs0J5YGTVKUD4ypucMbkF3G+TrUNssv0JmQJFS 3ISNQuI72jEQyQ==; Date: Thu, 03 Apr 2025 18:48:37 +0300 Message-Id: <86fripz1nu.fsf@gnu.org> From: Eli Zaretskii To: James Cherti In-Reply-To: <1258e18f-b8ad-4e53-b558-7c21835b3eda@jamescherti.com> (message from James Cherti on Thu, 3 Apr 2025 11:33:02 -0400) Subject: Re: bug#77438: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer =?utf-8?Q?=28Vim=E2=80=99s?= virtualedit=all Equivalent in Emacs) References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <86wmc223nd.fsf@gnu.org> <86ldsi1yrb.fsf@gnu.org> <1258e18f-b8ad-4e53-b558-7c21835b3eda@jamescherti.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Thu, 3 Apr 2025 11:33:02 -0400 > From: James Cherti > > Thank you for your comments, which helped clarify the purpose of > this feature request. > > If you have any ideas on how this could be implemented, whether or > not it involves changing the Emacs internals, please feel free to > share your insights. All of my suggestions were based on existing features. If they work and do the job you want this to do, you should be able to implement these features without any changes to the internals. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 03 22:51:36 2025 Received: (at 77438) by debbugs.gnu.org; 4 Apr 2025 02:51:36 +0000 Received: from localhost ([127.0.0.1]:36496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0X9c-00019b-02 for submit@debbugs.gnu.org; Thu, 03 Apr 2025 22:51:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56000) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0X9Y-00019L-KA for 77438@debbugs.gnu.org; Thu, 03 Apr 2025 22:51:33 -0400 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 1u0X9T-0006dL-0J; Thu, 03 Apr 2025 22:51:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:MIME-version:References:Subject:In-Reply-To:To: From; bh=lIa7IDgDwgw0/EwgXJ10EC/E3+f3Vs4B+TD4i9nY46o=; b=jArctixg1p/lfwlWyKF+ 1sJOnrKhTO+2ko1SlF+ID3bMY2huhUHumKgYMtifjTCW4SxEGMN7awvH+ze7xUR+3AlFUMYVUtujQ 9i0YYhnRVuczuVLyMK2U71Upi5mYS6vRbj04Q+5PIldw5xBxTXbJ7PTXaHzOwMXIDyiJ6ljDfADqq RlHK3PCGdtoZhzPRPilft/XiwXkn3SOFmjoRUOZhR2cVvmxhr6fSjmBrjXMVTVAJwbQr9A229fGJB hGNW4w4dinzRMe12tGsafMPx2mQd2kuYalvCGGaisXsnc2jXs0nrtKHLGg1LF8ntFVk5Y+4cefeOx Jg3GrRVFmFJRmA==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1u0X9R-0001HL-B6; Thu, 03 Apr 2025 22:51:25 -0400 From: Richard Stallman To: James Cherti In-Reply-To: <5c69553a-e6d6-4303-8800-416f99179f00@jamescherti.com> (message from James Cherti on Thu, 3 Apr 2025 11:30:12 -0400) Subject: Re: bug#77438: [FEATURE REQUEST] Freely positioning the cursor anywhere in the buffer =?utf-8?Q?=28Vim=C3=A2s?= virtualedit=all Equivalent in Emacs) References: <485aa4ab-4469-46af-9e7e-3a040411295d@jamescherti.com> <5c69553a-e6d6-4303-8800-416f99179f00@jamescherti.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Date: Thu, 03 Apr 2025 22:51:25 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77438 Cc: 77438@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Here’s an idea: instead of modifying the internal concept where the > cursor is equal to the position between two characters, we could > implement a new mode that displays a "virtual cursor." This mode > would display a cursor representing a specific line/column, rather > than a position between two characters. It would allow the cursor to > be placed at a line/column position, which may not necessarily be > between two characters. This would make display work as it should in this mode, with editing commands that have special code to update the virtual cursor. But if that will work only for commands that are updated with extra code to understand these virtual cursor positions. That would be an enormous amount of work and wuuld complicate future maintenance. A less ugly way to do this would be to modify the buffer contents model so that there can be virtual spaces at the end of the current line. But it won't be easy to make that work with full consistency for all commands that operate on or look at the buffer. Would the virtual spaces extend to the right margin? Would they extend only as far as he cursor? If you do C-SPC C-n M-w, what should that put in the kill ring? What about C-SPC C-u C-n M-w? One would need to figure out a system that gives the "right" answers for such questions. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)