Activity for MH-E
-
Mike Kupfer modified ticket #473
mh-refile-msg vs mh-thread-refile
-
Make web site compatible with PHP 8
-
Bill Wohler modified ticket #482
Incorrect usage of cl-flet
-
I'm going to have to agree with Mike. We'll put the flet bug to rest unless we hear otherwise. Resolving as fixed.
-
Fixed in a058d61615.
-
mh-funcall-if-exists ignores function if it wasn't there at compile time
-
This wasn't the only unused macro. The list of unused macros in mh-acros.el is: mh-do-in-gnu-emacs, mh-do-in-xemacs, mh-funcall-if-exists, defun-mh, defmacro-mh, mh-make-local-hook,mh-mark-active-p. These have been deleted on the master branch.
-
Stephen Gildea modified ticket #504
mh-mm-inline-media-tests needs an autoload cookie
-
This was fixed July 2023 by Bill Wohler, who added "(require 'mh-mime)" to mh-show.el with commit a92ee5ca3c.
-
mh-mm-inline-media-tests needs an autoload cookie
-
In fall 2021 (for Emacs 29), Stefan Kangas removed all calls to mh-funcall-if-exists and declared it obsolete. Probably all that remains to be done is to remove the definition itself.
-
Update copyrights
-
Make compatible with PHP 7; use a staging area for htdocs
-
Mike was wondering why the folder name is tied to the underlying search engine, and I would tend to agree that we should use the same folder name regardless of the search engine. Here's the search template: From: To: Cc: Date: Subject: I like the brevity of the mairix keywords. Thus, our folder name pattern could be: f:<from>_t:<to>_c:<cc>_d:<date>_s:<subject>_b:<body>_a:<anywhere>. It looks like it can be easily done by updating (mh-index-do-search) to pass regexp-list instead of pattern to (mh-search)....
-
Mike was wondering why the folder name is tied to the underlying search engine, and I would tend to agree that we should use the same folder name regardless of the search engine. Here's the search template: From: To: Cc: Date: Subject: I like the brevity of the mairix keywords. Thus, our pattern could be: f:<from>_t:<to>_c:<cc>_d:<date>_s:<subject>_b:_a:<anywhere>.</anywhere></subject></date></cc></to></from> It looks like it can be easily done by updating (mh-index-do-search) to pass regexp-list...
-
Mike was wondering why the folder name is tied to the underlying search engine, and I would tend to agree that we should use the same folder name regardless of the search engine. Here's the search template: From: To: Cc: Date: Subject: I like the brevity of the mairix keywords. Thus, our pattern could be: f:<from>_t:<to>_c:<cc>_d:<date>_s:<subject>_b:_a:<anywhere>.</anywhere></subject></date></cc></to></from> It looks like it can be easily done by updating (mh-index-do-search) to pass regexp-list...
-
I wanted to understand this a little better, so I ran (mh-pick-parse-search-buffer) on a search buffer with 123 in all fields. I then put the result in the variable "foo". Here are the results of calling the various regexp-builders and mh-index-generate-pretty-name. (setq foo '((nil . "123") (subject . "123") (date . "123") (cc . "123") (to . "123") (from . "123"))) (mh-swish++-regexp-builder foo) -> " 123 and (subject = 123) and (date = 123) and (cc = 123) and (to = 123) and (from = 123)" (mh-index-generate-pretty-name...
-
I wanted to understand this a little better, so I ran (mh-pick-parse-search-buffer) on a search buffer with 123 in all fields. I then put the result in the variable "foo". Here are the results of calling the various regexp-builders and mh-index-generate-pretty-name. (setq foo '((nil . "123") (subject . "123") (date . "123") (cc . "123") (to . "123") (from . "123"))) (mh-swish++-regexp-builder foo) -> " 123 and (subject = 123) and (date = 123) and (cc = 123) and (to = 123) and (from = 123)" (mh-index-generate-pretty-name...
-
search should not create folder with all-numeric name
-
mh-complete-word is unused
-
The fix for this will be in Emacs 29.1 (commit b3de81a6ee3).
-
mhparam change in nmh 1.7
-
You thought that "goto-address should leave text alone if it's already been propertized." And Eli seems to agree, but it seems that it might be risky at this late date. I might tend to agree. In your initial analysis, you suggested not using mh-show-addr if shr was in use. This seems much safer. You mention that shr allows one to click on the email address, so perhaps not too much is lost. Indeed, MH-E defers to other packages in most cases, so perhaps mh-show-addr should only be used as a last ...
-
I'd be inclined to do the same thing as mh-letter-complete if an alternative is available. That is, to rip out the function and mark it obsolete with its replacement. For example: +(define-obsolete-function-alias 'mh-letter-complete + #'completion-at-point "29.1") Otherwise, yes, just mark it obsolete and remove it in the next major version.
-
mh-complete-word is unused
-
Stefan Kangas has done some work here, e.g., removing mh-compat.el with 0a060a2bfe and b459e275c3, but it looks like there's still more to do.
-
Henrique Martins posted a comment on ticket #498
Got the patch from the emacs source. Haven't tested it yet. Thanks for fixing it.
-
provide better support for link checking (Emacs 29)
-
Raising the priority, as this is a new issue in Emacs 29 that we really ought to fix before Emacs 29 goes out the door.
-
mh-mime-save-parts prompt is broken
-
Fixed in Emacs 29.1 (2181495af8).
-
mh-kill-folder still uses mh-kill-folder-suppress-prompt-hooks
-
mh-execute-commands fails when default-directory no longer exists
-
Fixed in Emacs 29.1 (bb0af6489a).
-
mh-kill-folder still uses mh-kill-folder-suppress-prompt-hooks
-
mh-mime-save-parts prompt is broken
-
mh-mime-save-parts prompt is broken
-
The workaround for this bug is to kill the buffer *MH-E Log*
-
I checked for other instances in MH-E of this problem (default-directory getting munged by a cd) and didn't see any. I've got a preliminary patch for this issue that I'll try to get out for review next weekend. While I was testing, I noticed a problem with the prompt for mh-mime-save-parts. I've got a fix for that which I'll post for review at the same time.
-
mh-execute-commands fails when default-directory no longer exists
-
Sounds good. Hmmm, I wonder if we have other sleeping cd calls in our code... Mike Kupfer via mh-e-devel mh-e-devel@lists.sourceforge.net wrote: Yeah, I totally misread the docstring for "with-existing-directory", so forget that idea. Note that when saving attachments, it's a feature that the chosen directory is used the next time, so I'm not sure you'd want to switch directories back after the method. mh-mime-save-parts saves the chosen directory in mh-mime-save-parts-directory, which will get used...
-
Yeah, I totally misread the docstring for "with-existing-directory", so forget that idea. Note that when saving attachments, it's a feature that the chosen directory is used the next time, so I'm not sure you'd want to switch directories back after the method. mh-mime-save-parts saves the chosen directory in mh-mime-save-parts-directory, which will get used to generate the prompt the next time. That part's fine. It's the cd into the target directory, which sets default-directory for the buffer and...
-
Looking at the manual for with-existing-directory, the macro looks at default-directory rather than taking a directory as an argument. It doesn't say what it does if default-directory doesn't exist. Note that when saving attachments, it's a feature that the chosen directory is used the next time, so I'm not sure you'd want to switch directories back after the method. If with-existing-directory isn't helpful, I guess we should check for the existence of default-directory and cd to $HOME if it doesn't...
-
utf-8-encoded From field can clobber first part of subject in threaded mode
-
utf-8-encoded From field can clobber first part of subject in threaded mode
-
mh-execute-commands fails when default-directory no longer exists
-
I see that #'mh-mime-save-parts cd's into the directory, which would set default-directory, but it doesn't cd back after saving the MIME parts. I suspect it should use with-existing-directory, rather than cd.
-
Or maybe goto-address should leave text alone if it's already been propertized?
-
provide better support for link checking (Emacs 29)
-
The fontification of the suspicious link and the assignment of the mouse-over text to the warning emoji are done in #'shr-tag-a: (when url (shr-urlify (or shr-start start) (shr-expand-url url) title) ;; Check whether the URL is suspicious. (when-let ((warning (or (textsec-suspicious-p (shr-expand-url url) 'url) (textsec-suspicious-p (cons (shr-expand-url url) (buffer-substring (or shr-start start) (point))) 'link)))) (add-text-properties (or shr-start start) (point) (list 'face '(shr-link textsec-suspicious)))...
-
Here's a screenshot from Gnus, with the mouse over the warning emoji.
-
provide better support for link checking (Emacs 29)
-
mh-execute-commands fails when default-directory no longer exists
-
The raw email is attached as email.eml.
-
utf-8-encoded From field can clobber first part of subject in threaded mode
-
Back in October (2021), there was a question on mh-e-users, asking why each invocation of "F n" in a folder was producing a new, numbered unseen sequence folder in +mhe-search, rather than just reusing +mhe-search/sequence/unseen. The problem wasn't readily reproducible, so we never got to root cause. I have now seen the problem a couple times. In each case, there is an Emacs backup file (and no other files) in the directory for +mhe-search/sequence/unseen.
-
Cannot forward message with double-line From
-
This was fixed by commit 2a4de5e5e5, which will appear in Emacs 28.1. Thanks to Lester Buck for the assist.
-
MH-E released /MH-E Manual/README.md
-
-
-
-
In particular, the macros mh-do-in-gnu-emacs and mh-do-in-xemacs can be removed. The code wrapped by the former can be run unadorned and code wrapped by the latter can be deleted. The mh-funcall-if-exists macro should also be removed. Matthias made the following observation: This code in mh-junk.el (mh-spamassassin-allowlist) probably doesn't work as intended: (setq from (car (mh-funcall-if-exists ietf-drums-parse-address (mh-get-header-field "From:")))) Even if ietf-drums-parse-address were available,...
-
Remove XEmacs support
-
Good point, Mark. Thanks! I use !' when a message doesn't have a default folder. If the last folder was changed with a copy (which I use mainly now to put in my +todo hierarchy), a subsequent!' would put the next message in +todo (which I don't want) instead of the last folder I used for the individual or company (which I do). Mark Baushke mbaushke@gmail.com wrote: I actually do not agree with such a change. I often copy a message into a folder based on a topic and refile the same message into a...
-
While we're at it, it seems like copying a message should remember/use the last target folder.
-
Darel posted a comment on ticket #158
Mike Kupfer via mh-e-devel mh-e-devel@lists.sourceforge.net wrote: See also issue 495 [bugs:#158] K e doesn't work with a single body part Status: open Milestone: mh-e-8.0 Labels: mime Created: Fri Jan 07, 2005 07:02 PM UTC by Bill Wohler Last Updated: Sat Feb 23, 2013 09:22 PM UTC Owner: nobody If you have a message that doesn't have any body parts but a top-level content type that is not text/plain, you might want to view it with an external viewer. For example, text/html messages fall into this...
-
See also issue 495
-
broken URLs in user guide (X-Face)
-
message with "me" in cc: field don't get marked in scan listing
-
mh-funcall-if-exists ignores function if it wasn't there at compile time
-
improve handling of malformed HTML-only emails
-
improve handling of malformed HTML-only emails
-
I can reproduce this in 27.0.91. It appears to be a timing issue with external viewers. MH-E points all MIME viewers at the show buffer. This works well for internal viewers: they update the show buffer, they finish, and MH-E sets the buffer as unmodified. This strategy doesn't work as well with external viewers. An external viewer is a background process, and it might write logging or error messages to the show buffer after MH-E has called (set-buffer-modified-p nil).
-
mh-funcall-if-exists ignores function if it wasn't there at compile time
-
MH-E discards text properties in emacs > v24
-
Thanks, Mike, for reviewing my patch. I committed it to the emacs-27 release branch as 7f01dfca56.
-
minshall posted a comment on ticket #476
i also still see it.
-
I still see it sometimes with Emacs 26.3, particularly when viewing PDF files with Evince. The problem seems to happen when the viewer writes something to stderr; the error message ends up in the show buffer.
-
Is this still a bug? I used to get "buffer modified", but I no longer do with Emacs 25 or the 27 release branch.
-
I've seen three proposals for how to fix this display problem: call mh-show-mode earlier call mh-show-mode only if not already in MH-Show mode. call (font-lock-mode -1) To these I'll add a fourth; kill the Show buffer at the start of mh-show-msg. With all the resetting we do in mh-display-msg, just starting with a fresh buffer each time has the appeal of simplicity. Thus, option 4 seems good. There's also something to be said for calling mh-show-mode, which calls kill-all-local-variables, before...
-
the following appears to fix the problem. (note that the "zero" function here functions as an "else"). diff --git a/lisp/mh-e/mh-scan.el b/lisp/mh-e/mh-scan.el index f3ad7c68ba..c4f1c7dadf 100644 --- a/lisp/mh-e/mh-scan.el +++ b/lisp/mh-e/mh-scan.el @@ -76,11 +76,11 @@ mh-scan-format-nmh (concat "%4(msg)" "%<(cur)+%| %>" - "%<{replied}-" - "%?(nonnull(comp{to}))%<(mymbox{to})t%>" - "%?(nonnull(comp{cc}))%<(mymbox{cc})c%>" - "%?(nonnull(comp{bcc}))%<(mymbox{bcc})b%>" - "%?(nonnull(comp{newsgroups}))n%>"...
-
message with "me" in cc: field don't get marked in scan listing
-
move from cl to cl-lib
-
This was fixed by commit 74b097b61c5201405ad7bc5bb76f1ca0e794184b Author: Stefan Monnier monnier@iro.umontreal.ca Date: Tue Aug 6 03:56:51 2019 -0400 and will appear in Emacs 27.1.
-
broken URLs in user guide (X-Face)
-
well, i ran into this again today (and, searching the bugs, found this forgotten bit!:). not that i'm lobbying to have the priority increased, especially as it doesn't seem to have happened to anyone else. if i do "F u" (mh-undo-folder) in +outbox, the "q", i get an error (wrong-type-argument consp nil) in (mh-update-sequences). i think this is because (mh-find-seq 'cur) returns nil, which is then used (in variable seq-entry) as the target of a setcdr, which, i assume, generates the error. to reproduce:...
-
Test comment, please ignore.
-
See #479, which may be a duplicate and contains a test message.
-
It seems that way. If John's message reproduces the problem, and Peter's fix resolves it, then it would seem so. This can then be resolved as a duplicate.
-
Could this be related to #254?
-
See also #205
-
See also #486
-
mh-redistribute + identity is broken with nmh >= 1.5
-
This will be fixed in Emacs 27.1. commit e1646e1e2864d6eaf567f4fe77cc11d3e17dde51 Author: Mike Kupfer mkupfer@alum.berkeley.edu Date: Sat Aug 4 18:06:37 2018 -0700 Fix mh-redistribute to work with nmh 1.5 and identities (SF#268) Co-authored-by: Jeffrey C Honig <jch@honig.net> * lisp/mh-e/mh-comp.el (mh-redistribute): Add a non-optional identity parameter. Use mh-bare-components to generate a draft, then apply identity-specific settings. Add more details to the "Resent" annotation line. (mh-dist-formfile):...
-
mail composition broken with mailutils
-
Fixed by commit b73cde5e2815c531df7f5fd13e214a7d92f78239 Author: Mike Kupfer <mkupfer@alum.berkeley.edu> Date: Wed Jul 4 15:43:04 2018 -0700 Fix MH-E mail composition with GNU Mailutils (SF#485) * lisp/mh-e/mh-comp.el (mh-bare-components): Recursively delete the temporary folder. This will appear in Emacs 26.2.
-
I was able to "fix" the problem by disabling font-lock as part of the buffer reset that mh-display-msg does: (setq buffer-read-only nil) ;; Cleanup old mime handles (mh-mime-cleanup) (erase-buffer) ;; Changing contents, so this hook needs to be reinitialized. ;; pgp.el uses this. (if (boundp 'write-contents-hooks) ;Emacs 19 (kill-local-variable 'write-contents-hooks)) (font-lock-mode -1) And this does not break the fontification of the header or attributed text. But I can't tell whether this is a...
-
A little more experimentation shows that even if mh-highlight-citation-style is nil, MH-E ends up throwing away the fontification that shr did. Gnus doesn't seem to have these problems, so one possible way forward is to see how the MH-E message display code differs from the corresponding code in Gnus.
-
I was dinking around with this, and the problem is related to this block of code in mh-show-mode: (cond ((equal mh-highlight-citation-style 'font-lock) (setq font-lock-defaults '(mh-show-font-lock-keywords-with-cite t))) ((equal mh-highlight-citation-style 'gnus) (setq font-lock-defaults '((mh-show-font-lock-keywords) t nil nil nil (font-lock-fontify-region-function . mh-show-font-lock-fontify-region))) (mh-gnus-article-highlight-citation)) (t (setq font-lock-defaults '(mh-show-font-lock-keywords...
