gmane.mail.mh-e.devel

which-func-modes set to t

Mike Kupfer — 2013-05-21T00:34:44

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 when which-func-modes is t, not a
list?

thanks,
mike

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

Bill Wohler — 2013-05-13T04:46:08

- **labels**:  --> patch
- **status**: unread --> 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
&nbsp;&nbsp;mh-refile-msg
sets the variables
&nbsp;&nbsp;mh-last-destination
and
&nbsp;&nbsp;mh-last-destination-folder
to be used in future refiles, but
&nbsp;&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 <https://sourceforge.net/p/mh-e/bugs/473/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

Henrique Martins — 2013-05-11T16:31:09

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
&nbsp;&nbsp;mh-refile-msg
sets the variables
&nbsp;&nbsp;mh-last-destination
and
&nbsp;&nbsp;mh-last-destination-folder
to be used in future refiles, but
&nbsp;&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 <https://sourceforge.net/p/mh-e/bugs/473/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #473 mh-refile-msg vs mh-thread-refile

Henrique Martins — 2013-05-10T12:41:28



---

** [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
&nbsp;&nbsp;mh-refile-msg
sets the variables
&nbsp;&nbsp;mh-last-destination
and
&nbsp;&nbsp;mh-last-destination-folder
to be used in future refiles, but
&nbsp;&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 <https://sourceforge.net/p/mh-e/bugs/473/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

Re: unexpected error mesage

Bill Wohler — 2013-04-07T06:50:26

OK, great, thanks! I'll install it in the next release.

d.henman <dhenman< at >gmail.com> wrote:

Re: unexpected error mesage

d.henman — 2013-04-07T05:06:46

Bill, et al,

I installed the patch, compiled the new .elc and restarted emacs to be doubly sure and restrarted.  The patch takes care of the problem for me.  For some reason the patch didn't want to be applied automatically.  I did carefully manually apply it.  If Zeus is having trouble I could send him the patched file.  Let me know.

Bill, thanks for creating the patch.

Darel


Bill Wohler <wohler< at >newt.com> wrote:


------------------------------------------------------------------------------
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/employer_resources/index.html

[mh-e:bugs] #472 The variable mh-unseen-seq is set whenUnseen_Sequence does not exist

Bill Wohler — 2013-04-07T00:24:23


---

** [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 <https://sourceforge.net/p/mh-e/bugs/472/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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/employer_resources/index.html_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #471 MH-Folder buffer includes "scan: bad message listunseen"

Bill Wohler — 2013-04-07T00:08:56

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 <https://sourceforge.net/p/mh-e/bugs/471/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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/employer_resources/index.html_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #471 MH-Folder buffer includes "scan: bad message listunseen"

Bill Wohler — 2013-04-07T00:07:39


---

** [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 <https://sourceforge.net/p/mh-e/bugs/471/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>------------------------------------------------------------------------------
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/employer_resources/index.html_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

Re: unexpected error mesage

Bill Wohler — 2013-04-07T00:01:46


I agree with you. Assuming that there aren't any objections from other
developers, I'll leave mh-unseen-seq alone if unset and ensure the code
can handle that.

However, that doesn't fix the problem. If you do have an Unseen-Sequence
entry, but do not have an unseen sequence at the moment, you'll still
get the error. This error is normally masked by MH-E, but the current
version fails to identify the error message. I think the following patch
will fix the problem while remaining backwards compatible. Zeus and
Darel, can you please try it and let me know how it goes?

Re: unexpected error mesage

Sergey Poznyakoff — 2013-04-03T09:51:47

Hello,

On March 31, Sergey Poznyakoff <gray< at >gnu.org.ua> wrote:


While implementing it, it turned out that this sequence is not
"built-in" even in traditional implementations.  That is, unless you
explicitly set "Unseen-Sequence: unseen" in your ~/.mh_profile,
"scan unseen" will complain both in traditional MH and in nmh.  To
wit:

$ ./xscan -help|grep version
version: MH 6.8.4 #25[UCI] (ulysses) of Thu Mar 28 23:54:38 EET 2013
$ ./xscan unseen
xscan: bad message list unseen

This makes me think that relying on "unseen" as a built-in default in
MH-E is incorrect.  I'm referring to lines 212-215 in mh-utils.el:

        (setq mh-unseen-seq (mh-profile-component "Unseen-Sequence"))
        (if mh-unseen-seq
            (setq mh-unseen-seq (intern mh-unseen-seq))
          (setq mh-unseen-seq 'unseen))     ;old MH default?

I would rather suppose that mh-unseen-seq should remain nil and not be used
at all if Unseen-Sequence is not explicitly set.  What would you say?

Regards,
Sergey

PS: This, of course, does not change what I said earlier about "unseen"
support in Mailutils, which will appear soon.


------------------------------------------------------------------------------
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/employer_resources/index.html

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Bill Wohler — 2013-03-16T20:44:28

- **status**: unread --> closed-wont-fix
- **milestone**:  --> 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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_mar_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Bill Wohler — 2013-03-16T20:44:28

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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_mar_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Kevin Layer — 2013-03-06T03:28:22

The hang happened again.  This time I attached with gdb and got a backtrace:

    (gdb) where
    #0  get_next_display_element (it=it< at >entry=0x7fffcbfe5990) at xdisp.c:6472
    #1  0x0000000000439142 in move_it_in_display_line_to (it=it< at >entry=0x7fffcbfe5990, to_charpos=to_charpos< at >entry=-1, to_x=to_x< at >entry=-1, op=op< at >entry=(unknown: 0)) at xdisp.c:8152
    #2  0x000000000043efc7 in move_it_to (it=it< at >entry=0x7fffcbfe5990, to_charpos=to_charpos< at >entry=-1, to_x=to_x< at >entry=-1, to_y=to_y< at >entry=-1, to_vpos=19, op=op< at >entry=4) at xdisp.c:8608
    #3  0x0000000000445992 in move_it_by_lines (it=0x7fffcbfe5990, dvpos=<optimized out>) at xdisp.c:9085
    #4  0x000000000044a1c7 in try_scrolling (window=window< at >entry=66032789, just_this_one_p=just_this_one_p< at >entry=1, arg_scroll_conservatively=101, scroll_step=1, temp_scroll_step=1, last_line_misfit=last_line_misfit< at >entry=0) at xdisp.c:14628
    #5  0x000000000045b782 in redisplay_window (window=66032789, just_this_one_p=just_this_one_p< at >entry=1) at xdisp.c:15716
    #6  0x000000000045cc76 in redisplay_window_1 (window=window< at >entry=66032789) at xdisp.c:13756
    #7  0x0000000000572a69 in internal_condition_case_1 (bfun=bfun< at >entry=0x45cc40 <redisplay_window_1>, arg=66032789, handlers=11956006, hfun=hfun< at >entry=0x429030 <redisplay_window_error>) at eval.c:1552
    #8  0x0000000000447c75 in redisplay_internal () at xdisp.c:13381
    #9  0x0000000000449bb5 in redisplay () at xdisp.c:12528
    #10 0x0000000000508f20 in read_char (commandflag=1, nmaps=nmaps< at >entry=3, maps=maps< at >entry=0x7fffcbfebc90, prev_event=11985394, used_mouse_menu=used_mouse_menu< at >entry=0x7fffcbfebdc0, end_time=0x0, end_time< at >entry=0x7fffcbfebc90) at keyboard.c:2448
    #11 0x000000000050b3c7 in read_key_sequence (keybuf=keybuf< at >entry=0x7fffcbfebea0, prompt=11985394, dont_downcase_last=dont_downcase_last< at >entry=0, can_return_switch_frame=can_return_switch_frame< at >entry=1, fix_current_buffer=fix_current_buffer< at >entry=1, bufsize=30) at keyboard.c:9328
    #12 0x000000000050d23c in command_loop_1 () at keyboard.c:1449
    #13 0x0000000000572921 in internal_condition_case (bfun=bfun< at >entry=0x50d050 <command_loop_1>, handlers=12037682, hfun=hfun< at >entry=0x501d70 <cmd_error>) at eval.c:1514
    #14 0x000000000050079e in command_loop_2 (ignore=ignore< at >entry=11985394) at keyboard.c:1160
    #15 0x000000000057281b in internal_catch (tag=0, func=func< at >entry=0x500780 <command_loop_2>, arg=11985394) at eval.c:1271
    #16 0x000000000050183f in command_loop () at keyboard.c:1139
    #17 recursive_edit_1 () at keyboard.c:759
    #18 0x0000000000501b6d in Frecursive_edit () at keyboard.c:823
    #19 0x0000000000414a1d in main (argc=3, argv=<optimized out>) at emacs.c:1715
    (gdb) 


And, interestingly, when I did a "kill" of the process, the SIGINT caused it to break out of the hard loop it was in and be usable.

---

** [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:** Tue Mar 05, 2013 11:23 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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Ted Phelps — 2013-03-05T11:23:12

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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_feb_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Kevin Layer — 2013-03-04T15:36:08

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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_feb_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #470 mh-e discards text properties in emacs > v24

Ted Phelps — 2013-03-04T11:19:39

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 > 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 <https://sourceforge.net/p/mh-e/bugs/470/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_feb_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #470 mh-e discards text properties in emacs > v24

Ted Phelps — 2013-03-04T11:17:35


---

** [bugs:#470] mh-e discards text properties in emacs > 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 <https://sourceforge.net/p/mh-e/bugs/470/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_feb_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[mh-e:bugs] #267 1st line of MH-Show buffer indented

Ted Phelps — 2013-03-04T11:03:33

Lars Mange Ingebrigtsen, the shr author, has pushed the patch into the emacs mainline.  It's now <a href="http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/111935">r111935</a>.

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 <https://sourceforge.net/p/mh-e/bugs/267/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>------------------------------------------------------------------------------
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/appdyn_d2d_feb_______________________________________________
mh-e-devel mailing list
mh-e-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

Re: Massive Developers Guide update

d.henman — 2013-03-03T09:40:30

Bill,
   I appreciate you efforts and look forward to using the new version and reading the new developer's manual 

Thanks,
  Darel

------------------------------------------------------------------------------
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/appdyn_d2d_feb

Massive Developers Guide update

Bill Wohler — 2013-03-03T02:26:41

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, Tickets, which replaces
the previously separate Bugs, Feature Requests, Patches, and Support
sections. It should reflect what we have discussed.

Finally, I revamped Section 10, Releases. It's probably worth a skim so
you know how I use the various tools on SourceForge.

Of note to you includes Section 10.1, Release Schedule which discusses
(in addition to Section 9.3, Milestone) our new use of the Milestone
field which is a far departure of how we used to use the Group field.

You may also find Section 10.4, Release Prerequisites helpful if you
need to merge changes back and forth between the Emacs trunk and mh-e
branches if I'm not around to do so.

Questions, comments, and fixes welcome!