GNU bug report logs - #60666
30.0.50; [PATCH] Use field properties in Eshell buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60666 in the body.
You can then email your comments to 60666 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Sun, 8 Jan 2023 15:34:03 -0800

[Message part 1 (text/plain, inline)]

This was prompted by a small annoyance I noticed in Eshell. When 
entering a command in an Eshell buffer, "C-a" takes you to the beginning 
of your input, but the Home key takes you all the way to the beginning 
of the line (so that the point is located within the the actual prompt 
text).

After digging through the Eshell code, I realized that this was because 
Eshell binds C-a to 'eshell-bol', but doesn't do the same for Home. The 
easiest way to fix this would be to add a binging for Home. However, 
when comparing this code to that of 'M-x shell', I noticed that the 
latter uses field properties to delimit parts of the shell buffer so 
that things Just Work. I think that's a more-robust way of doing things, 
and it would be nice to make Eshell do the same.

Attached are some patches to do this. Aside from the user-facing change 
that the Home key works like C-a now, this also means that users don't 
have to set 'eshell-prompt-regexp' anymore (unless they want to use 
paragraph navigation, that is). In fact, maybe it would be better to map 
M-{ and M-} to 'eshell-prompt-(previous|next)'. That would have the same 
effect as '(backward|forward)-paragraph' (I think), but it would be more 
robust.

Any thoughts here?

[0001-Set-the-field-property-for-Eshell-output.patch (text/plain, attachment)]

[0002-Make-eshell-bol-obsolete.patch (text/plain, attachment)]

[0003-Use-the-field-property-to-navigate-through-Eshell-pr.patch (text/plain, attachment)]

Message #8 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Mon, 09 Jan 2023 14:09:43 +0200

> Date: Sun, 8 Jan 2023 15:34:03 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> Attached are some patches to do this. Aside from the user-facing change 
> that the Home key works like C-a now, this also means that users don't 
> have to set 'eshell-prompt-regexp' anymore (unless they want to use 
> paragraph navigation, that is). In fact, maybe it would be better to map 
> M-{ and M-} to 'eshell-prompt-(previous|next)'. That would have the same 
> effect as '(backward|forward)-paragraph' (I think), but it would be more 
> robust.
> 
> Any thoughts here?

The only thought I have is "what if anyone _does_ like Home to do what
it does now?"  So this change should have a NEWS ebtry about the
incompatible changes, and a recipe for how to get back the old
behavior for those who want it.

Thanks.

Message #11 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Mon, 9 Jan 2023 09:52:53 -0800

[Message part 1 (text/plain, inline)]

On 1/9/2023 4:09 AM, Eli Zaretskii wrote:
> The only thought I have is "what if anyone _does_ like Home to do what
> it does now?"  So this change should have a NEWS ebtry about the
> incompatible changes, and a recipe for how to get back the old
> behavior for those who want it.

Thanks, that makes sense. I've added a NEWS entry to the first part (see 
attached). The recipe seems like it's on the edge of what would be 
reasonable for users to paste into their configs though. I don't have a 
strong opinion here, but if you think the recipe is too long, maybe we 
could add the 'move-beginning-of-line-ignoring-fields' function to 
simple.el. It might possibly be useful for some small number of people 
who want to selectively disable field text motion.

[0001-Set-the-field-property-for-Eshell-output.patch (text/plain, attachment)]

Message #14 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Tue, 10 Jan 2023 14:13:46 +0200

> Date: Mon, 9 Jan 2023 09:52:53 -0800
> Cc: 60666 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 1/9/2023 4:09 AM, Eli Zaretskii wrote:
> > The only thought I have is "what if anyone _does_ like Home to do what
> > it does now?"  So this change should have a NEWS ebtry about the
> > incompatible changes, and a recipe for how to get back the old
> > behavior for those who want it.
> 
> Thanks, that makes sense. I've added a NEWS entry to the first part (see 
> attached). The recipe seems like it's on the edge of what would be 
> reasonable for users to paste into their configs though. I don't have a 
> strong opinion here, but if you think the recipe is too long, maybe we 
> could add the 'move-beginning-of-line-ignoring-fields' function to 
> simple.el. It might possibly be useful for some small number of people 
> who want to selectively disable field text motion.

I don't think I understand why keeping eshell-bol and telling people
to bind <HOME> to that function if they want wouldn't be a much more
reasonable solution.  I'm probably missing something.

Adding a function that is used in just two places doesn't sound TRT to
me.

Message #17 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Tue, 10 Jan 2023 11:28:17 -0800

On 1/10/2023 4:13 AM, Eli Zaretskii wrote:
> I don't think I understand why keeping eshell-bol and telling people
> to bind <HOME> to that function if they want wouldn't be a much more
> reasonable solution.  I'm probably missing something.

Do you mean that users who want <home> to go to the very beginning of 
the line would bind it to 'eshell-bol'? If so, that wouldn't help. 
'eshell-bol' moves the point to the beginning of the user's input, not 
the actual beginning of the line.

If you mean the other way, and that users who want <home> to go to the 
beginning of the input should just bind it to 'eshell-bol', that would 
help, but then we wouldn't get the benefits of using 'field' properties 
in Eshell. One of the nice things about using 'field' properties is that 
'eshell-prompt-regexp' is no longer necessary[1]. That regexp is fairly 
brittle. Also, users who customize their prompt need to make sure they 
update it correctly.

Here's an example of the brittleness. Starting from "emacs -Q -f eshell":

  ~ $ mkdir "folder #1"
  ~ $ cd "folder #1"
  ~/folder #1 $ |
                ^-- Point is here

Now press C-a. Normally, that should take you to the beginning of the 
input, but it takes you to the beginning of the whole line because the 
prompt regexp isn't robust enough. Even worse, because Eshell can't tell 
where the user's input starts, completion doesn't work on that line. (We 
could probably fix this particular case by just tweaking 
'eshell-prompt-regexp', but I don't think it could ever work in *all* 
cases, whereas it shouldn't be hard to get perfection with 'field' 
properties.)

Avoiding the need for 'eshell-prompt-regexp' also makes it simpler to 
customize the Eshell prompt. Currently, it's just another thing to set, 
and it's easy to get it wrong (it took me several tries to get it right 
in my own configuration). The next patch I have planned for Eshell will 
make it easier to customize the prompt[2], so getting rid of 
'eshell-prompt-regexp' would be nice for any users who want to finally 
try customizing the prompt.

[1] Except for using it to set 'paragraph-start' in Eshell.

[2] I plan to use 'format-mode-line' and provide some mode-line 
constructs ("prompt constructs"?) for Eshell. Then users will have a 
small toolbox of constructs they could use for their prompts.

Message #20 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Tue, 10 Jan 2023 22:11:31 +0200

> Date: Tue, 10 Jan 2023 11:28:17 -0800
> Cc: 60666 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 1/10/2023 4:13 AM, Eli Zaretskii wrote:
> > I don't think I understand why keeping eshell-bol and telling people
> > to bind <HOME> to that function if they want wouldn't be a much more
> > reasonable solution.  I'm probably missing something.
> 
> Do you mean that users who want <home> to go to the very beginning of 
> the line would bind it to 'eshell-bol'? If so, that wouldn't help. 
> 'eshell-bol' moves the point to the beginning of the user's input, not 
> the actual beginning of the line.

That's not what I see in Emacs 29.  C-a moves to the beginning of
input, i.e. it stops at the end of the prompt, whereas HOME goes all
the way to the beginning of screen line, including the prompt.

"C-h c" says that C-a is bound to eshell-bol, but HOME is bound to
move-beginning-of-line.

I'm asking why not let users have this distinction after your change,
with some easy customization?

> If you mean the other way, and that users who want <home> to go to the 
> beginning of the input should just bind it to 'eshell-bol', that would 
> help, but then we wouldn't get the benefits of using 'field' properties 
> in Eshell. One of the nice things about using 'field' properties is that 
> 'eshell-prompt-regexp' is no longer necessary[1]. That regexp is fairly 
> brittle. Also, users who customize their prompt need to make sure they 
> update it correctly.

I understand the benefits, but from user POV we just removed some
functionality as the price of making maintenance easier.  That is not
a good balance for users who want the removed functionality.

Message #23 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Tue, 10 Jan 2023 12:51:14 -0800

On 1/10/2023 12:11 PM, Eli Zaretskii wrote:
> That's not what I see in Emacs 29.  C-a moves to the beginning of
> input, i.e. it stops at the end of the prompt, whereas HOME goes all
> the way to the beginning of screen line, including the prompt.
> 
> "C-h c" says that C-a is bound to eshell-bol, but HOME is bound to
> move-beginning-of-line.
> 
> I'm asking why not let users have this distinction after your change,
> with some easy customization?

It sounds like we agree but we're looking at this from different 
directions. Since my patch adds the 'field' property, a user can't just 
use 'move-beginning-of-line' to go to the very beginning of the line 
(instead, it stops at the end of the prompt, where the field property ends).

I agree that an easy customization to restore the old behavior would be 
nice. The old behavior has been around a long time, so I'm sure some 
people have come to rely on it.

One option would be to add a new function like 'eshell-really-bol' (with 
a better name, of course), that calls 'move-beginning-of-line' and 
ignores fields, like the function I suggested in the NEWS entry. This 
function wouldn't be used anywhere by default, but it makes it easy for 
users to restore the behavior. This is probably the simplest, most 
direct way.

Another option might be to enhance 'move-beginning-of-line'. Maybe we 
could add an option so that calling it the first time obeys field 
boundaries, but if you immediately call it again, it ignores them. Then, 
a user who wants to go to the real beginning of a line can just press 
<home> (or C-a) twice. That's not exactly the same as the old behavior, 
but it would be usable outside of Eshell, and it's pretty close to 
maintaining muscle memory: you just need to press the same key again. 
Something like this might be sufficient, if we add a defcustom to toggle 
this behavior:

----------------------------------------

diff --git a/lisp/simple.el b/lisp/simple.el
index 690968ca938..803c5ee07e4 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8174,6 +8174,9 @@ move-beginning-of-line
         (goto-char (previous-char-property-change (point)))
         (goto-char (line-beginning-position))))

+    (let ((inhibit-field-text-motion
+           (if (eq last-command #'move-beginning-of-line)
+               t inhibit-field-text-motion)))
     ;; Now find first visible char in the line.
     (while (and (< (point) orig) (invisible-p (point)))
       (goto-char (next-char-property-change (point) orig)))
@@ -8189,7 +8192,7 @@ move-beginning-of-line
 		 ;; Otherwise, move to START with attention to fields.
 		 ;; (It is possible that fields never matter in this case.)
 		 (constrain-to-field (point) orig
-				     (/= arg 1) t nil)))))
+				     (/= arg 1) t nil))))))


 ;; Many people have said they rarely use this feature, and often type

----------------------------------------

The above is something I've occasionally wished for in other places. As 
a workaround, I usually press "C-a C-b C-a" (or "<home> <left> <home>"), 
but being able to press "C-a C-a" (or "<home> <home>") would be easier, 
and probably more robust.

Message #26 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Wed, 11 Jan 2023 14:15:29 +0200

> Date: Tue, 10 Jan 2023 12:51:14 -0800
> Cc: 60666 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 1/10/2023 12:11 PM, Eli Zaretskii wrote:
> > That's not what I see in Emacs 29.  C-a moves to the beginning of
> > input, i.e. it stops at the end of the prompt, whereas HOME goes all
> > the way to the beginning of screen line, including the prompt.
> > 
> > "C-h c" says that C-a is bound to eshell-bol, but HOME is bound to
> > move-beginning-of-line.
> > 
> > I'm asking why not let users have this distinction after your change,
> > with some easy customization?
> 
> It sounds like we agree but we're looking at this from different 
> directions. Since my patch adds the 'field' property, a user can't just 
> use 'move-beginning-of-line' to go to the very beginning of the line 
> (instead, it stops at the end of the prompt, where the field property ends).
> 
> I agree that an easy customization to restore the old behavior would be 
> nice. The old behavior has been around a long time, so I'm sure some 
> people have come to rely on it.
> 
> One option would be to add a new function like 'eshell-really-bol' (with 
> a better name, of course), that calls 'move-beginning-of-line' and 
> ignores fields, like the function I suggested in the NEWS entry. This 
> function wouldn't be used anywhere by default, but it makes it easy for 
> users to restore the behavior. This is probably the simplest, most 
> direct way.

I think 'eshell-really-bol' is the best alternative here, yes.  Then
NEWS could tell users to bind it to HOME or whatever.

> Another option might be to enhance 'move-beginning-of-line'. Maybe we 
> could add an option so that calling it the first time obeys field 
> boundaries, but if you immediately call it again, it ignores them. Then, 
> a user who wants to go to the real beginning of a line can just press 
> <home> (or C-a) twice. That's not exactly the same as the old behavior, 
> but it would be usable outside of Eshell, and it's pretty close to 
> maintaining muscle memory: you just need to press the same key again. 

Because this is not exactly the old behavior, I don't think it alone
can be the response to backward-compatibility need.  It could be a
separate new feature, of course.

Message #29 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Thu, 12 Jan 2023 10:10:09 -0800

[Message part 1 (text/plain, inline)]

On 1/11/2023 4:15 AM, Eli Zaretskii wrote:
> I think 'eshell-really-bol' is the best alternative here, yes.  Then
> NEWS could tell users to bind it to HOME or whatever.

Ok, done.

I also updated the implementation of 
'eshell-(forward|backward)-matching-input' to benefit from fields. (I 
didn't notice these functions earlier.) This reimplementation makes it 
work better than before, since you can now search for a regexp like 
"^echo" to find only inputs that *started* with "echo". Previously, that 
wasn't possible. I also added a regression test for it.

[0001-Set-the-field-property-for-Eshell-output.patch (text/plain, attachment)]

[0002-Make-eshell-bol-obsolete.patch (text/plain, attachment)]

[0003-Use-the-field-property-to-navigate-through-Eshell-pr.patch (text/plain, attachment)]

Message #32 received at 60666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60666 <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Fri, 13 Jan 2023 15:07:17 +0200

> Date: Thu, 12 Jan 2023 10:10:09 -0800
> Cc: 60666 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 1/11/2023 4:15 AM, Eli Zaretskii wrote:
> > I think 'eshell-really-bol' is the best alternative here, yes.  Then
> > NEWS could tell users to bind it to HOME or whatever.
> 
> Ok, done.
> 
> I also updated the implementation of 
> 'eshell-(forward|backward)-matching-input' to benefit from fields. (I 
> didn't notice these functions earlier.) This reimplementation makes it 
> work better than before, since you can now search for a regexp like 
> "^echo" to find only inputs that *started* with "echo". Previously, that 
> wasn't possible. I also added a regression test for it.

Thanks, I'm happy now.

Message #37 received at 60666-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60666-done <at> debbugs.gnu.org
Subject: Re: bug#60666: 30.0.50; [PATCH] Use field properties in Eshell buffers
Date: Sat, 14 Jan 2023 11:30:59 -0800

On 1/13/2023 5:07 AM, Eli Zaretskii wrote:
> Thanks, I'm happy now.

Thanks. I've merged this as c257fd3a406d6aa83be60b96217e42b49b62cf5f. 
Closing this bug now.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.