Bill Wohler
2016-01-18 05:35:21 UTC
- **status**: unread --> open
---
** [bugs:#450] Document scoped variables that are useful in hooks**
**Status:** open
**Milestone:** mh-e-8.0.3
**Created:** Sun Nov 19, 2006 11:53 PM UTC by Bill Wohler
**Last Updated:** Sat Feb 23, 2013 09:17 PM UTC
**Owner:** nobody
and that seems like the best place to me.
Well, this is how the variables look like when called in
mh-letter-mode-hook
mh-sent-from-folder
nil
;-------------------------------------------
mh-show-buffer
nil
;-------------------------------------------
\(get-buffer mh-show-buffer\)
"Wrong type argument: stringp"
;-------------------------------------------
mh-sent-from-msg
nil
;-------------------------------------------
Thomas,
Notice that mh-letter-mode is called from mh-compose-and-send-mail so you have visibility to the arguments there such as sent-from-folder and sent-from-msg. You also have visibility to the variable show-buffer in mh-reply.
I see three options for MH-E:
1\. Leave these undocumented and subject to change \(although the chance of this is minuscule\). This can be done now ;-\).
2\. Document these variables since they seem to be useful. I don't think I like this option as all documented variables currently start with mh-. It's only advantage is I could do it now. But we'd be stuck with it, so no.
3\. Add mh- prefixes to these variables, leave them scoped, and document them. This option fixes the issues I have with \#2, but would have to wait until after the release since we're in feature freeze.
4\. Add mh- prefixes to these variables, make them buffer local in the show buffer and draft \(rather than just the mh-folder-mode buffer as they are now\), and document them. This option does have a certain appeal since the availability of variables wouldn't be surprising, but it would have to wait until after the release since it would involve quite a bit of changes.
Comments? Is there any reason why variables shouldn't be documented in the first place? They do seem as they would be very useful to the user to me.
\----- End of included email -----
I don't know which approach would be better: \#3 or \#4. I invite your thoughts on this.
I think we should also look at other hooks and see if there are other undocumented, scoped variables that should be renamed and documented in a similar fashion.
---
Sent from sourceforge.net because mh-e-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/mh-e/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [bugs:#450] Document scoped variables that are useful in hooks**
**Status:** open
**Milestone:** mh-e-8.0.3
**Created:** Sun Nov 19, 2006 11:53 PM UTC by Bill Wohler
**Last Updated:** Sat Feb 23, 2013 09:17 PM UTC
**Owner:** nobody
mh-letter-mode-hook is too early because the replied message is not yet
available, mh-before-send-hook seems to be too late if you want to
retain control of the identity selection. Is there any hook in between?
Actually, the replied message should be available in mh-letter-mode-hookavailable, mh-before-send-hook seems to be too late if you want to
retain control of the identity selection. Is there any hook in between?
and that seems like the best place to me.
mh-letter-mode-hook
mh-sent-from-folder
nil
;-------------------------------------------
mh-show-buffer
nil
;-------------------------------------------
\(get-buffer mh-show-buffer\)
"Wrong type argument: stringp"
;-------------------------------------------
mh-sent-from-msg
nil
;-------------------------------------------
Notice that mh-letter-mode is called from mh-compose-and-send-mail so you have visibility to the arguments there such as sent-from-folder and sent-from-msg. You also have visibility to the variable show-buffer in mh-reply.
I see three options for MH-E:
1\. Leave these undocumented and subject to change \(although the chance of this is minuscule\). This can be done now ;-\).
2\. Document these variables since they seem to be useful. I don't think I like this option as all documented variables currently start with mh-. It's only advantage is I could do it now. But we'd be stuck with it, so no.
3\. Add mh- prefixes to these variables, leave them scoped, and document them. This option fixes the issues I have with \#2, but would have to wait until after the release since we're in feature freeze.
4\. Add mh- prefixes to these variables, make them buffer local in the show buffer and draft \(rather than just the mh-folder-mode buffer as they are now\), and document them. This option does have a certain appeal since the availability of variables wouldn't be surprising, but it would have to wait until after the release since it would involve quite a bit of changes.
Comments? Is there any reason why variables shouldn't be documented in the first place? They do seem as they would be very useful to the user to me.
\----- End of included email -----
I don't know which approach would be better: \#3 or \#4. I invite your thoughts on this.
I think we should also look at other hooks and see if there are other undocumented, scoped variables that should be renamed and documented in a similar fashion.
---
Sent from sourceforge.net because mh-e-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/mh-e/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.