Mike Kupfer | 21 May 2013 02:34
Picon
Favicon

which-func-modes set to t

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
(Continue reading)

Bill Wohler | 13 May 2013 06:46
Gravatar

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

  • 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
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  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
Henrique Martins | 11 May 2013 18:31

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

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
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  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
Henrique Martins | 10 May 2013 14:41

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

[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
  mh-refile-msg
sets the variables
  mh-last-destination
and
  mh-last-destination-folder
to be used in future refiles, but
  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
Bill Wohler | 7 Apr 2013 02:24
Gravatar

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

[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
Bill Wohler | 7 Apr 2013 02:08
Gravatar

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

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
Bill Wohler | 7 Apr 2013 02:07
Gravatar

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

[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
Bill Wohler | 16 Mar 2013 21:44
Gravatar

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

  • 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
Bill Wohler | 16 Mar 2013 21:44
Gravatar

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

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
Kevin Layer | 6 Mar 2013 04:28

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

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, opan>=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> span>) 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
Ted Phelps | 5 Mar 2013 12:23

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

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

Gmane