From: Stefan Kangas <stefankangas@gmail.com>
To: "Simen Heggestøyl" <simenheg@runbox.com>
Cc: 67000@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#67000: 30.0.50; [PATCH] Add support for reading/writing IELM input history
Date: Sat, 13 Jan 2024 01:08:49 -0600 [thread overview]
Message-ID: <CADwFkmk+Rchnzzj3B1twgWy3ZRTPmg5XcBix4YxxXfjwUU-VqA@mail.gmail.com> (raw)
In-Reply-To: <874jfibkju.fsf@runbox.com>
Simen Heggestøyl <simenheg@runbox.com> writes:
>>> +(unless noninteractive
>>> + (add-hook 'kill-emacs-hook #'comint-write-input-ring))
>>
>> I'm not so sure about this part. If this is correct, why should it be
>> defined here, and not, say, in comint.el? It seems like a separate,
>> unrelated change. What am I missing?
>
> Usually comint-derived modes use a process sentinel to listen to some
> external process and call `comint-write-input-ring' when the process
> exists, which works both the buffer is killed or Emacs itself is quit.
>
> For IELM there is no such process to listen to, so I hook into
> `kill-buffer-hook' and `kill-emacs-hook' to achieve the same things.
I'm not against adding a hook to `kill-emacs-hook', but it should be
added when you start IELM and not on top-level. We want to avoid any
side effects from merely loading a file.
I don't think this will work in its current form either: AFAICT,
`comint-write-input-ring' saves it for the current buffer, and that's
not guaranteed to be the *ielm* buffer when `kill-emacs-hook' runs.
So you'd want to first switch to that buffer, I think. It could also
have been renamed meanwhile, so I think you want to save the actual
buffer and not it's name (i.e. use `get-buffer').
next prev parent reply other threads:[~2024-01-13 7:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 15:11 bug#67000: 30.0.50; [PATCH] Add support for reading/writing IELM input history Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-15 1:06 ` Stefan Kangas
2024-01-04 7:46 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 20:17 ` Stefan Kangas
2024-01-08 7:30 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 19:51 ` Stefan Kangas
2024-01-12 16:09 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-13 7:08 ` Stefan Kangas [this message]
2024-01-19 7:48 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 15:09 ` Stefan Kangas
2024-02-07 14:02 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-10 11:28 ` Stefan Kangas
2024-02-15 7:53 ` Simen Heggestøyl via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADwFkmk+Rchnzzj3B1twgWy3ZRTPmg5XcBix4YxxXfjwUU-VqA@mail.gmail.com \
--to=stefankangas@gmail.com \
--cc=67000@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=simenheg@runbox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.