http://blog.gmane.org/gmane.mail.mh-e.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.mail.mh-e.devel/13594 <pre>Hi, Which Function mode recently got added to XEmacs, and it broke my (old) MH-E 8 package. The problem is that which-func-modes is being defaulted to t, which then causes an error in (add-to-list 'which-func-modes 'mh-folder-mode) The fix that I see in Emacs is to check whether which-func-modes is a list: ;; Register mh-folder-mode as supporting which-function-mode... ... (when (and (boundp 'which-func-modes) (listp which-func-modes)) (add-to-list 'which-func-modes 'mh-folder-mode)) I can certainly cherry-pick that fix, but there's something going on here that I don't understand. The documentation for which-func-modes says (in both Emacs and XEmacs) If this is equal to t, then Which Function mode is enabled in any major mode that supports it. So how does Emacs know what major modes support Which Function mode? The comment in mh-folder.el (reproduced above) implies that major modes register themselves by adding to which-func-modes. So how are things supposed to work whe</pre> Mike Kupfer 2013-05-21T00:34:44 http://comments.gmane.org/gmane.mail.mh-e.devel/13593 <pre>- **labels**: --&gt; patch - **status**: unread --&gt; open --- ** [bugs:#473] mh-refile-msg vs mh-thread-refile** **Status:** open **Labels:** patch **Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins **Last Updated:** Sat May 11, 2013 04:31 PM UTC **Owner:** nobody Seems that &amp;nbsp;&amp;nbsp;mh-refile-msg sets the variables &amp;nbsp;&amp;nbsp;mh-last-destination and &amp;nbsp;&amp;nbsp;mh-last-destination-folder to be used in future refiles, but &amp;nbsp;&amp;nbsp;mh-thread-refile does not sets those thus things can get a bit confusing if one does a few of each in succession. Shouldn't the behavior be identical? --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/473/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and thei</pre> Bill Wohler 2013-05-13T04:46:08 http://comments.gmane.org/gmane.mail.mh-e.devel/13591 <pre>Looks like copying a few lines from mh-refile-msg to mh-thread-refile, and adding an optional argument to mh-thread-refile, like the one in mh-refile-msg does the trick. Attaching patch. Attachment: mh-thread-refile.patch (778 Bytes; text/x-patch) --- ** [bugs:#473] mh-refile-msg vs mh-thread-refile** **Status:** unread **Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins **Last Updated:** Fri May 10, 2013 12:41 PM UTC **Owner:** nobody Seems that &amp;nbsp;&amp;nbsp;mh-refile-msg sets the variables &amp;nbsp;&amp;nbsp;mh-last-destination and &amp;nbsp;&amp;nbsp;mh-last-destination-folder to be used in future refiles, but &amp;nbsp;&amp;nbsp;mh-thread-refile does not sets those thus things can get a bit confusing if one does a few of each in succession. Shouldn't the behavior be identical? --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/473/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;---------------------------</pre> Henrique Martins 2013-05-11T16:31:09 http://comments.gmane.org/gmane.mail.mh-e.devel/13589 <pre> --- ** [bugs:#473] mh-refile-msg vs mh-thread-refile** **Status:** unread **Created:** Fri May 10, 2013 12:41 PM UTC by Henrique Martins **Last Updated:** Fri May 10, 2013 12:41 PM UTC **Owner:** nobody Seems that &amp;nbsp;&amp;nbsp;mh-refile-msg sets the variables &amp;nbsp;&amp;nbsp;mh-last-destination and &amp;nbsp;&amp;nbsp;mh-last-destination-folder to be used in future refiles, but &amp;nbsp;&amp;nbsp;mh-thread-refile does not sets those thus things can get a bit confusing if one does a few of each in succession. Shouldn't the behavior be identical? --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/473/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leader</pre> Henrique Martins 2013-05-10T12:41:28 http://comments.gmane.org/gmane.mail.mh-e.devel/13586 <pre> --- ** [bugs:#472] The variable mh-unseen-seq is set when Unseen_Sequence does not exist** **Status:** open **Created:** Sun Apr 07, 2013 12:24 AM UTC by Bill Wohler **Last Updated:** Sun Apr 07, 2013 12:24 AM UTC **Owner:** Bill Wohler Sergey points out that we set mh-unseen-seq to "unseen" if Unseen-Sequence is not defined. His feeling is that we should leave mh-unseen-seq as nil in this case. Thus, remove this case and check that the code handles a nil mh-unseen-seq gracefully. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/472/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/emp</pre> Bill Wohler 2013-04-07T00:24:23 http://comments.gmane.org/gmane.mail.mh-e.devel/13585 <pre>The solution here seems to flush the buffer of any common scan output and not change the check depending on the variant in use. --- ** [bugs:#471] MH-Folder buffer includes "scan: bad message list unseen"** **Status:** open **Created:** Sun Apr 07, 2013 12:07 AM UTC by Bill Wohler **Last Updated:** Sun Apr 07, 2013 12:07 AM UTC **Owner:** Bill Wohler Darel and Zeus have reported that they have seen "scan: bad message list unseen" messages when they run mh-rmail. They use GNU Mailutils. It appears that newer versions of Mailutils use the same message as nmh, rather than what we used to expect namely, "scan: message set .* does not exist." --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/471/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management an</pre> Bill Wohler 2013-04-07T00:08:56 http://comments.gmane.org/gmane.mail.mh-e.devel/13584 <pre> --- ** [bugs:#471] MH-Folder buffer includes "scan: bad message list unseen"** **Status:** open **Created:** Sun Apr 07, 2013 12:07 AM UTC by Bill Wohler **Last Updated:** Sun Apr 07, 2013 12:07 AM UTC **Owner:** Bill Wohler Darel and Zeus have reported that they have seen "scan: bad message list unseen" messages when they run mh-rmail. They use GNU Mailutils. It appears that newer versions of Mailutils use the same message as nmh, rather than what we used to expect namely, "scan: message set .* does not exist." --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/471/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/subscriptions/&gt;------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http:</pre> Bill Wohler 2013-04-07T00:07:39 http://comments.gmane.org/gmane.mail.mh-e.devel/13581 <pre>- **status**: unread --&gt; closed-wont-fix - **milestone**: --&gt; Unassigned --- ** [bugs:#267] 1st line of MH-Show buffer indented** **Status:** closed-wont-fix **Created:** Sun Jul 01, 2012 12:36 PM UTC by Kevin Layer **Last Updated:** Wed Mar 06, 2013 03:28 AM UTC **Owner:** nobody With Emacs 24.1 + Gnus 5.13 + MH-E 8.3.1 I get this behavior: After showing a multi-part email w/HTML, subsequent messages have the first line in the MH-Show buffer indented increasingly more. I have attached a message that triggers the problem for me. Viewing messages after showing this message have indenting first lines. This happens with emacs -q. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/267/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynam</pre> Bill Wohler 2013-03-16T20:44:28 http://comments.gmane.org/gmane.mail.mh-e.devel/13580 <pre>Closing, per Ted's request. Looks like this should be resolved when Emacs 24.4 is released. --- ** [bugs:#267] 1st line of MH-Show buffer indented** **Status:** closed-wont-fix **Created:** Sun Jul 01, 2012 12:36 PM UTC by Kevin Layer **Last Updated:** Wed Mar 06, 2013 03:28 AM UTC **Owner:** nobody With Emacs 24.1 + Gnus 5.13 + MH-E 8.3.1 I get this behavior: After showing a multi-part email w/HTML, subsequent messages have the first line in the MH-Show buffer indented increasingly more. I have attached a message that triggers the problem for me. Viewing messages after showing this message have indenting first lines. This happens with emacs -q. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/267/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics </pre> Bill Wohler 2013-03-16T20:44:28 http://comments.gmane.org/gmane.mail.mh-e.devel/13579 <pre> The hang happened again. This time I attached with gdb and got a backtrace: (gdb) where #0 get_next_display_element (it=it&lt; at &gt;entry=0x7fffcbfe5990) at xdisp.c:6472 #1 0x0000000000439142 in move_it_in_display_line_to (it=it&lt; at &gt;entry=0x7fffcbfe5990, to_charpos=to_charpos&lt; at &gt;entry=-1, to_x=to_x&lt; at &gt;entry=-1, op=op&lt; at &gt;entry=(unknown: 0)) at xdisp.c:8152 #2 0x000000000043efc7 in move_it_to (it=it&lt; at &gt;entry=0x7fffcbfe5990, to_charpos=to_charpos&lt; at &gt;entry=-1, to_x=to_x&lt; at &gt;entry=-1, to_y=to_y&lt; at &gt;entry=-1, to_vpos=19, op=op&lt; at &gt;entry=4) at xdisp.c:8608 #3 0x0000000000445992 in move_it_by_lines (it=0x7fffcbfe5990, dvpos=&lt;optimized out&gt;) at xdisp.c:9085 #4 0x000000000044a1c7 in try_scrolling (window=window&lt; at &gt;entry=66032789, just_this_one_p=just_this_one_p&lt; at &gt;entry=1, arg_scroll_conservatively=101, scroll_step=1, temp_scroll_step=1, last_line_misfit=last_line_misfit&lt; at &gt;entry=0) at xdisp.c:14628 #5 0x000000000045b782 in redisplay_window (window=66032789, just_this_one_p=just_this_one_p&lt; at &gt;entry=1) at xdisp.c:15716 #6 0x0000</pre> Kevin Layer 2013-03-06T03:28:22 http://comments.gmane.org/gmane.mail.mh-e.devel/13578 <pre>Bill, I reckon this is as fixed as it's going to get. I don't see any way to change the status though, so I'm guess that I don't have the necessary rights. Would you like to close it? Thanks, -Ted --- ** [bugs:#267] 1st line of MH-Show buffer indented** **Status:** unread **Created:** Sun Jul 01, 2012 12:36 PM UTC by Kevin Layer **Last Updated:** Mon Mar 04, 2013 03:36 PM UTC **Owner:** nobody With Emacs 24.1 + Gnus 5.13 + MH-E 8.3.1 I get this behavior: After showing a multi-part email w/HTML, subsequent messages have the first line in the MH-Show buffer indented increasingly more. I have attached a message that triggers the problem for me. Viewing messages after showing this message have indenting first lines. This happens with emacs -q. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/267/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;---------------------------------------------------------------</pre> Ted Phelps 2013-03-05T11:23:12 http://comments.gmane.org/gmane.mail.mh-e.devel/13577 <pre>Ted, for some reason I can't reproduce it any longer. Let's consider it a glitch of some sort. I've been using the patch since and not seen any other problems. Thanks for the work to fix this! --- ** [bugs:#267] 1st line of MH-Show buffer indented** **Status:** unread **Created:** Sun Jul 01, 2012 12:36 PM UTC by Kevin Layer **Last Updated:** Mon Mar 04, 2013 11:03 AM UTC **Owner:** nobody With Emacs 24.1 + Gnus 5.13 + MH-E 8.3.1 I get this behavior: After showing a multi-part email w/HTML, subsequent messages have the first line in the MH-Show buffer indented increasingly more. I have attached a message that triggers the problem for me. Viewing messages after showing this message have indenting first lines. This happens with emacs -q. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/267/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;-------------------------------------------------------------------</pre> Kevin Layer 2013-03-04T15:36:08 http://comments.gmane.org/gmane.mail.mh-e.devel/13576 <pre>The attachment above, 12703, is an example e-mail that displays the behavior. Note that you must enable shr as your HTML renderer to see the true horror. Also attached is a patch that works around the problem. It might make more sense to render the HTML after mh-show-mode is invoked, but that looks trickier to achieve. -Ted Attachment: mh-show.el.diff (915 Bytes; application/octet-stream) --- ** [bugs:#470] mh-e discards text properties in emacs &gt; v24** **Status:** unread **Created:** Mon Mar 04, 2013 11:17 AM UTC by Ted Phelps **Last Updated:** Mon Mar 04, 2013 11:17 AM UTC **Owner:** nobody While chasing bug 267, I noticed that the text-mode function, which is called by mh-show-mode, discards all text properties. HTML e-mail rendered via shr.el gets rendered first, and then mh-show-mode is invoked: all of the careful highlighting and coloring is thrown away. Amusingly, the overlays shr uses to pad tables remain, so the result not the improvement you might think. -Ted --- Sent from sourceforg</pre> Ted Phelps 2013-03-04T11:19:39 http://comments.gmane.org/gmane.mail.mh-e.devel/13575 <pre> --- ** [bugs:#470] mh-e discards text properties in emacs &gt; v24** **Status:** unread **Created:** Mon Mar 04, 2013 11:17 AM UTC by Ted Phelps **Last Updated:** Mon Mar 04, 2013 11:17 AM UTC **Owner:** nobody While chasing bug 267, I noticed that the text-mode function, which is called by mh-show-mode, discards all text properties. HTML e-mail rendered via shr.el gets rendered first, and then mh-show-mode is invoked: all of the careful highlighting and coloring is thrown away. Amusingly, the overlays shr uses to pad tables remain, so the result not the improvement you might think. -Ted --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/470/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/a</pre> Ted Phelps 2013-03-04T11:17:35 http://comments.gmane.org/gmane.mail.mh-e.devel/13574 <pre>Lars Mange Ingebrigtsen, the shr author, has pushed the patch into the emacs mainline. It's now &lt;a href="http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/111935"&gt;r111935&lt;/a&gt;. Kevin, have you had any luck getting a stack trace or core file? -Ted --- ** [bugs:#267] 1st line of MH-Show buffer indented** **Status:** unread **Created:** Sun Jul 01, 2012 12:36 PM UTC by Kevin Layer **Last Updated:** Sat Feb 23, 2013 09:17 PM UTC **Owner:** nobody With Emacs 24.1 + Gnus 5.13 + MH-E 8.3.1 I get this behavior: After showing a multi-part email w/HTML, subsequent messages have the first line in the MH-Show buffer indented increasingly more. I have attached a message that triggers the problem for me. Viewing messages after showing this message have indenting first lines. This happens with emacs -q. --- Sent from sourceforge.net because you indicated interest in &lt;https://sourceforge.net/p/mh-e/bugs/267/&gt; To unsubscribe from further messages, please visit &lt;https://sourceforge.net/auth/prefs/&gt;------------</pre> Ted Phelps 2013-03-04T11:03:33 http://comments.gmane.org/gmane.mail.mh-e.devel/13572 <pre>Hey folks, I just updated the Developers Guide (http://mh-e.sourceforge.net/doc/devguide.html) to version 2.0 while putting out MH-E 8.5: * doc/devguide.texi (EDITION): Change to 2.0. Make changes related to SourceForge 2.0 upgrade. Update name of tools: Bugs, Feature Requests, Patches, and Support are now under a single tool called Tickets. Rename the Group field, which spanned both Fixed In and Found In concepts, to Milestones and now use it to assign a ticket to a particular release. Update URLs. Change ChangeLog dates to reflect the change is checked into Emacs. Rename Category to Labels. Merge Resolution into Status and reduce the number of possible statuses. Add bzr information for merging changes between trunk and mh-e branches. Please have a look at the update to Section 6, Bazaar Repository which talks about our mh-e branch. I updated the rest of the document to assume that we do all of our work on that branch. Next, take a look at the brand-new Section 9</pre> Bill Wohler 2013-03-03T02:26:41 http://comments.gmane.org/gmane.mail.mh-e.devel/13571 <pre>The MH-E manual for MH-E 8.5 corrects the URLs due to the SourceForge 2.0 upgrade. Read on for more details. Project home page at: http://mh-e.sourceforge.net/. 2013-03-02 Bill Wohler &lt;wohler&lt; at &gt;newt.com&gt; Release MH-E manual version 8.5. * mh-e.texi (VERSION, EDITION, UPDATED, UPDATE-MONTH): Update for release 8.5. * mh-e.texi (Preface, Conventions, Getting Started) (Using This Manual, Folder Selection, Viewing, Aliases) (Identities, Speedbar, Menu Bar, Tool Bar, Scan Line Formats) (Bug Reports, Mailing Lists, MH FAQ and Support, Getting MH-E): Update URLs. 2013-03-02 Bill Wohler &lt;wohler&lt; at &gt;newt.com&gt; Release MH-E manual version 8.5. * README: Update for release 8.5. </pre> Bill Wohler 2013-03-03T01:40:39 http://comments.gmane.org/gmane.mail.mh-e.devel/13570 <pre>Project home page at: http://mh-e.sourceforge.net/. * Changes in MH-E 8.5 Version 8.5 fixes bugs when incorporating or forwarding mail. ** Bug Fixes in MH-E 8.5 *** mh-rmail doesn't switch to +inbox The function `mh-rmail' now switches to `+inbox' as expected (closes SF #271). *** Problem forwarding a messsage Forwarding messages resulted in the error: `(wrong-type-argument number-or-marker-p nil).' This has been fixed by setting the mail separator (closes SF #270). </pre> Bill Wohler 2013-03-03T01:39:07 http://comments.gmane.org/gmane.mail.mh-e.devel/13564 <pre>I made the following changes to the labels: Added label "support" to support requests. Added label "patch" to patches. Deleted label "general". Downcased existing labels. Here are the current labels: contrib documentation mime patch security support ui I made the following changes to the workflow: open -&gt; unread unread -&gt; unread pending -&gt; open open-accepted -&gt; open open-works-for-me -&gt; open open-later -&gt; open closed -&gt; closed-fixed closed-fixed closed-invalid closed-works-for-me closed-wont-fix closed-duplicate closed-rejected -&gt; closed-works-for-me or closed-wont-fix closed-accepted -&gt; closed-fixed I ended up going with closed-fixed instead of just closed to be more specific and to ease searches on closed-*. Therefore, the new workflow is simply: unread --&gt; open --&gt; closed-* closed = closed-fixed | closed-invalid | closed-works-for-me | closed-wont-fix | closed-duplicate I updated the Open and C</pre> Bill Wohler 2013-02-23T23:01:31 http://comments.gmane.org/gmane.mail.mh-e.devel/13561 <pre>Hey folks, I'm starting the reshuffling, so I'd suggest not adding bugs or commenting on existing bugs until further notice. It's going to take a little longer than I had expected, but it won't be longer than this afternoon. </pre> Bill Wohler 2013-02-23T16:34:01 http://comments.gmane.org/gmane.mail.mh-e.devel/13560 <pre>The second task for Saturday morning is to simplify the workflow. Please find attached the discussion about that. I've also reserved the weekend of 3/2 - 3/3 to create a couple of MH-E releases. The first should cover the hidden +inbox issue, and the other should cover MH 1.5 issues. Feel free to join the bug squashing party on #mh-e or maybe even on a Google+ hangout... </pre> Bill Wohler 2013-02-18T20:05:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.mh-e.devel