GNU bug report logs - #77082
[PATCH] Add some more Eshell history tests

Previous Next

Package: emacs;

Reported by: Morgan Smith <Morgan.J.Smith <at> outlook.com>

Date: Mon, 17 Mar 2025 19:53:02 UTC

Severity: normal

Tags: patch

To reply to this bug, email your comments to 77082 AT debbugs.gnu.org.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#77082; Package emacs. (Mon, 17 Mar 2025 19:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Morgan Smith <Morgan.J.Smith <at> outlook.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 17 Mar 2025 19:53:02 GMT) Full text and rfc822 format available.

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

From: Morgan Smith <Morgan.J.Smith <at> outlook.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add some more Eshell history tests
Date: Mon, 17 Mar 2025 15:52:15 -0400
[Message part 1 (text/plain, inline)]
Tags: patch

This patch just adds some tests so I don't think that should be too
controversial

I have included some comments in the patch that I would like to talk
about though.

In the test `em-hist-test/eshell-history-file-name/nil' we don't save
any history to a file because `eshell-history-file-name' is nil and the
environment variable HISTFILE is unset.  I would like to see some user
visible warning here.  In theory this could be intended behavior to
prevent any history from being saved to disk but I think the more likely
case is the user accidentally misconfigured it.


I added a comment to the existing test
`em-hist-test/write-history/overwrite-multiple-shells' as I don't like
the behavior it demonstrates.  I was experiencing the occasional history
loss for years before I finally decided to investigate and now I know to
set `eshell-history-append' to true.

While writing this email I discovered Bug#66700 which seemed to come to
the conclusion that we should set `eshell-history-append' to true in the
next version of Emacs.  However, this would effectively make
`eshell-hist-ignoredups' useless.  I would be interested in a solution
where we check if the histfile has been updated to make sure we
overwrite without history loss.

[0001-Add-some-more-Eshell-history-tests.patch (text/patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#77082; Package emacs. (Mon, 17 Mar 2025 23:16:04 GMT) Full text and rfc822 format available.

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Morgan Smith <Morgan.J.Smith <at> outlook.com>, 77082 <at> debbugs.gnu.org
Subject: Re: bug#77082: [PATCH] Add some more Eshell history tests
Date: Mon, 17 Mar 2025 16:15:43 -0700
On 3/17/2025 12:52 PM, Morgan Smith wrote:
> This patch just adds some tests so I don't think that should be too
> controversial

Thanks for the contribution to the tests. I'll take a look at the tests 
themselves when I have a bit more time. In the meantime though, I can 
comment on, well... your comments.

> While writing this email I discovered Bug#66700 which seemed to come to
> the conclusion that we should set `eshell-history-append' to true in the
> next version of Emacs.  However, this would effectively make
> `eshell-hist-ignoredups' useless.

I don't think that's true. 'eshell-hist-ignoredups' is mainly useful so 
that if you run the same command several times (e.g. "make"), it only 
shows up in the history once. It can *also* help with storing history 
from multiple Eshell sessions, but it's probably not the best way to do 
that.

(For multiple Eshell sessions, I'd personally prefer a *global* history 
that updates immediately across all sessions, with the ability to use 
that global history *or* the session's local history. That's how I have 
Zsh configured, and I think it's the easiest way to handle history by 
quite a bit.)

> +  ;; It might be nice to warn the user in this case!  That would have
> +  ;; saved me time debugging my init file.

I find the 'nil' behavior for 'eshell-history-file-name' odd, but 
perhaps for a different reason: I'd expect 'nil' to mean "never store 
history", which you might possibly set for ephemeral Eshell sessions. 
Some value like 'use-histfile' for the current meaning of 'nil' would 
have been clearer, in my opinion. That would be an incompatible change 
though, so I've just left it as-is.

> +  ;; Is this really the behavior we want?  This is how eshell comes out
> +  ;; of the box with zero configuration.  Users using multiple eshells
> +  ;; are going to be missing history in a way that is going to be hard
> +  ;; for them to track down as it depends on when shells are opened and
> +  ;; closed relative to each other.

It's not. I think 'eshell-history-append' should be the default, but we 
wanted users to opt in first so that we'd have time to get feedback 
about the feature before it became the default.




This bug report was last modified 89 days ago.

Previous Next


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