bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[N. Jackson]

I'm trying to set up a Gnus posting style that makes use of the
‘message-reply-headers’ variable, but the behaviour I see indicates that
this variable is always nil (in the context where the posting styles are
evaluated).

It seems (this is a wild guess) that the function
`gnus-configure-posting-styles' that applies the posting styles that
match, and which is called from `message-mode-hook' (I believe), is
called before `message-reply-headers' is set.

Either that, or `gnus-configure-posting-styles' is evaluated in the
context of the wrong buffer (`message-reply-headers' is buffer local to
the *unsent reply...* buffer).

In (info "(gnus)Posting Styles") it says:

   The attribute value can be a string, a function with zero arguments
  (the return value will be used), a variable (its value will be used)
  or a list (it will be ‘eval’ed and the return value will be used). The
  functions and sexps are called/‘eval’ed in the message buffer that is
  being set up. The headers of the current article are available through
  the ‘message-reply-headers’ variable, which is a vector of the
  following headers: number subject from date id references chars lines
  xref extra.

If I am understanding this documentation correctly,
`message-reply-headers' should be available when posting styles are
evaluated.

===

For example, with the following test setting for `gnus-posting-styles',

  (setq gnus-posting-styles
    '((""		; Catch all posting style.
       (eval (if message-reply-headers
		(message "`message-reply-headers' is set.")
		(message "`message-reply-headers' is not set."))
       )
      )
     )
  )

If I reply to a message in the Gnus summary buffer

  R		; `gnus-summary-reply-with-original'.

the following message is printed in the echo area:

  `message-reply-headers' is not set.

. But if I then do

  C-h v message-reply-headers RET

(in the new *unsent reply...* buffer), I'm told

  message-reply-headers is a variable defined in `message.el'.
  Its value is
  [0 "Re: Packing of union fields and bool_bf" "Eli Zaretskii <eliz@gnu.org>" "Sat, 13 Oct 2018 18:15:25 +0300" "<838t31vpwy.fsf@gnu.org>" nil 0 0 ""]
  Local in buffer *unsent reply to Eli Zaretskii*; global value is nil

  Documentation:
  The headers of the current replied article.
  It is a vector of the following headers:
  [number subject from date id references chars lines xref extra].

  [back]

Am I missing something here, or is the Gnus posting styles functionality broken?

Note: To be fair, the paragraph quoted above from the Gnus manual only
says that `message-reply-headers' can be used for the attribute value;
it doesn't say that it can be used when the "attribute" is `eval'.
However, the following does not work either (no "Cc" header is inserted
in the new message):

  (setq gnus-posting-styles
    '((""		; Catch all posting style.
       ;; Set the "Cc" header of the new message to the "From"
       ;; address of the replied-to message.
       (Cc (elt message-reply-headers 2))
       )
      )
     )
  )

but evaluating `(elt message-reply-headers 2)' in the new *unsent
reply...* buffer gives a good value, and furthermore (just to narrow
down where the problem is), the following works fine (the "Cc" header is
inserted):

  (setq gnus-posting-styles
    '((""		; Catch all posting style.
       ;; Set the "Cc" header of the new message to the "From"
       ;; address of the replied-to message.
       (Cc "john.doe@example.com")
       )
      )
     )
  )

.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2018-10-24 built on moondust.localdomain
Repository revision: 00027ff9d0f646662458bdb47cc7e2214f439698
Windowing system distributor 'Fedora Project', version 11.0.11906000
System Description: Fedora 27 (Workstation Edition)

Configured using:
 'configure 'CFLAGS=-O3 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LCMS2 GMP

Important settings:
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  hl-line-mode: t
  TeX-PDF-mode: t
  diff-auto-refine-mode: t
  pdf-occur-global-minor-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  display-battery-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  save-place-mode: t
  electric-pair-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Features:
(shadow emacsbug misearch multi-isearch eieio-opt speedbar sb-image
ezimage dframe debug backtrace sort mm-archive gnus-bcklg gnus-cite
bbdb-message sendmail cl-print help-fns radix-tree gnus-async qp
mail-extr gnus-ml disp-table hl-line nndraft nnmh utf-7 gnutls epa-file
network-stream nnfolder bbdb-gnus nnnil gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime dig nntp gnus-cache dired-aux preview prv-emacs tex-buf font-latex
latex latex-flymake flymake-proc flymake thingatpt tex-ispell tex-style
tex dbus tex-mode vc-git diff-mode sh-script smie executable
org-duration org-eldoc flyspell ispell org-w3m org-rmail org-mhe org-irc
org-info org-habit org-gnus nnir gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
parse-time gnus-spec gnus-int gnus-range message rfc822 mml mml-sec epa
gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs mail-utils org-docview doc-view org-bibtex bibtex
org-bbdb pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet dired-x dired
dired-loaddefs pdf-isearch pdf-misc imenu pdf-tools compile cus-edit
pdf-view bookmark pp jka-compr pdf-cache pdf-info tq pdf-util image-mode
org-agenda org-element avl-tree generator org advice org-macro
org-footnote org-pcomplete org-list org-faces org-entities time-date
noutline outline easy-mmode org-version ob-shell shell pcomplete ob-R
ob-python ob-plantuml ob-org ob-gnuplot ob-ditaa ob-calc calc-store
calc-trail calc-ext calc calc-loaddefs calc-macs ob-awk ob-dot ob-maxima
ob-latex ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func bbdb-mua
bbdb-anniv diary-lib diary-loaddefs cal-menu calendar cal-loaddefs
bbdb-com crm mailabbrev bbdb bbdb-site timezone ido debbugs soap-client
mm-decode mm-bodies mm-encode url-http url-auth mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap warnings rng-xsd rng-dt rng-util xsd-regexp
xml edmacro kmacro recentf tree-widget wid-edit battery time
wheatgrass-theme paren savehist saveplace elec-pair desktop frameset
delsel cua-base cus-start cus-load mule-util tex-site ess-generics info
finder-inf package let-alist derived pcase cl-extra help-mode easymenu
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map url-vars seq byte-opt gv bytecomp
byte-compile cconv epg epg-config subr-x cl-loaddefs cl-lib tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 758095 175653)
 (symbols 48 113738 1)
 (strings 32 193416 20794)
 (string-bytes 1 6153705)
 (vectors 16 90152)
 (vector-slots 8 2130710 378334)
 (floats 8 520 948)
 (intervals 56 13519 113)
 (buffers 992 90))

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Eric Abrahamsen]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> I'm trying to set up a Gnus posting style that makes use of the
> ‘message-reply-headers’ variable, but the behaviour I see indicates that
> this variable is always nil (in the context where the posting styles are
> evaluated).
>
> It seems (this is a wild guess) that the function
> `gnus-configure-posting-styles' that applies the posting styles that
> match, and which is called from `message-mode-hook' (I believe), is
> called before `message-reply-headers' is set.
>
> Either that, or `gnus-configure-posting-styles' is evaluated in the
> context of the wrong buffer (`message-reply-headers' is buffer local to
> the *unsent reply...* buffer).

So far as I can tell, the problem is the former --
`gnus-configure-posting-styles' is called before `message-reply-headers'
is set.

Both `message-reply' and `message-followup' first call
`message-pop-to-buffer' (which ends up calling `message-mode' and thus
the `message-mode-hooks', and thus `gnus-configure-posting-styles').

Then they set `message-reply-headers'.

Then they call `message-setup', which calls `message-setup-1', which
runs the `message-setup-hook', which would be a spot where
`message-reply-headers' would be accessible.

I will check and see if this changed sometime recently.

I would say that posting-style configuration could be moved to the
`message-setup-hook', except that that would be guaranteed to wreck all
manner of existing configurations and get us lots of angry emails.

But... I think that's the issue.

E

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Glenn Morris]

Hi, please reply-to-all else the submitter won't see your response if
they aren't subscribed to the bug list.

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Eric Abrahamsen]

Sorry, hit the wrong key.

On 12/05/18 16:05 PM, Glenn Morris wrote:
> Hi, please reply-to-all else the submitter won't see your response if
> they aren't subscribed to the bug list.

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[N. Jackson]

At 12:54 -0800 on Wednesday 2018-12-05, Eric Abrahamsen wrote:

> "N. Jackson" <nljlistbox2@gmail.com> writes:
>
>> I'm trying to set up a Gnus posting style that makes use of the
>> ‘message-reply-headers’ variable, but the behaviour I see indicates that
>> this variable is always nil (in the context where the posting styles are
>> evaluated).
>>
>> It seems (this is a wild guess) that the function
>> `gnus-configure-posting-styles' that applies the posting styles that
>> match, and which is called from `message-mode-hook' (I believe), is
>> called before `message-reply-headers' is set.
>>
>> Either that, or `gnus-configure-posting-styles' is evaluated in the
>> context of the wrong buffer (`message-reply-headers' is buffer local to
>> the *unsent reply...* buffer).
>
> So far as I can tell, the problem is the former --
> `gnus-configure-posting-styles' is called before `message-reply-headers'
> is set.
>
> Both `message-reply' and `message-followup' first call
> `message-pop-to-buffer' (which ends up calling `message-mode' and thus
> the `message-mode-hooks', and thus `gnus-configure-posting-styles').
>
> Then they set `message-reply-headers'.
>
> Then they call `message-setup', which calls `message-setup-1', which
> runs the `message-setup-hook', which would be a spot where
> `message-reply-headers' would be accessible.
>
> I will check and see if this changed sometime recently.

I haven't been able to convince myself that `message-reply-headers' can
ever have worked properly with Gnus posting styles. 

> I would say that posting-style configuration could be moved to the
> `message-setup-hook',

That sounds right, I think. 

> except that that would be guaranteed to wreck all manner of existing
> configurations and get us lots of angry emails.

Maybe. I haven't been able to think of how it would negatively affect
existing setups, but probably I'm just lacking in imagination!

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Eric Abrahamsen]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> At 12:54 -0800 on Wednesday 2018-12-05, Eric Abrahamsen wrote:
>
>> "N. Jackson" <nljlistbox2@gmail.com> writes:
>>

[...]

>> I will check and see if this changed sometime recently.
>
> I haven't been able to convince myself that `message-reply-headers' can
> ever have worked properly with Gnus posting styles. 
>
>> I would say that posting-style configuration could be moved to the
>> `message-setup-hook',
>
> That sounds right, I think. 

The other possibility is: `gnus-configure-posting-styles' adds all its
actions to `message-setup-hook'. Perhaps the way it's meant to work is:
g-c-p-s adds *forms* to the message-setup-hook, but those forms aren't
actually evaluated until the hook is running, at which point we should
have access to everything we need.

I would need to look more closely at it to tell if that's the case, or
if it *could* be the case, but it would be one way that this code might
once have worked.

>> except that that would be guaranteed to wreck all manner of existing
>> configurations and get us lots of angry emails.
>
> Maybe. I haven't been able to think of how it would negatively affect
> existing setups, but probably I'm just lacking in imagination!

You'd be amazed at the number of ways things can blow up!

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> "N. Jackson" <nljlistbox2@gmail.com> writes:
>
>> At 12:54 -0800 on Wednesday 2018-12-05, Eric Abrahamsen wrote:
>>
>>> "N. Jackson" <nljlistbox2@gmail.com> writes:
>>>
>
> [...]
>
>>> I will check and see if this changed sometime recently.
>>
>> I haven't been able to convince myself that `message-reply-headers' can
>> ever have worked properly with Gnus posting styles. 
>>
>>> I would say that posting-style configuration could be moved to the
>>> `message-setup-hook',
>>
>> That sounds right, I think. 
>
> The other possibility is: `gnus-configure-posting-styles' adds all its
> actions to `message-setup-hook'. Perhaps the way it's meant to work is:
> g-c-p-s adds *forms* to the message-setup-hook, but those forms aren't
> actually evaluated until the hook is running, at which point we should
> have access to everything we need.

Just noticed that gnus-msg.el doesn't have lexical-binding set to t. I'm
not clever enough to know, without sitting down to think, how that might
affect things, but it's something to look at. Need to go out now,
though...

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Just noticed that gnus-msg.el doesn't have lexical-binding set to t. I'm
> not clever enough to know, without sitting down to think, how that might
> affect things, but it's something to look at. Need to go out now,
> though...

It shouldn't affect things in this area in one way or another -- all
these variables are defvarred and therefore have dynamic extent...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Just noticed that gnus-msg.el doesn't have lexical-binding set to t. I'm
>> not clever enough to know, without sitting down to think, how that might
>> affect things, but it's something to look at. Need to go out now,
>> though...
>
> It shouldn't affect things in this area in one way or another -- all
> these variables are defvarred and therefore have dynamic extent...

I'll try turning it on locally and see what happens.

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> The other possibility is: `gnus-configure-posting-styles' adds all its
> actions to `message-setup-hook'. Perhaps the way it's meant to work is:
> g-c-p-s adds *forms* to the message-setup-hook, but those forms aren't
> actually evaluated until the hook is running, at which point we should
> have access to everything we need.
>
> I would need to look more closely at it to tell if that's the case, or
> if it *could* be the case, but it would be one way that this code might
> once have worked.

Sounds reasonable to me...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Óscar Fuentes]

I discovered this bug report after wasting some time trying to figure
out what was wrong with my code. Emacs 26.1 here.

Activating lexical binding in gnus-msg.el has no effect.

bug#33140: 27.0.50; `gnus-posting-styles' sees nil ‘message-reply-headers’ variable

[Lars Ingebrigtsen]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> Either that, or `gnus-configure-posting-styles' is evaluated in the
> context of the wrong buffer (`message-reply-headers' is buffer local to
> the *unsent reply...* buffer).
>
> In (info "(gnus)Posting Styles") it says:
>
>    The attribute value can be a string, a function with zero arguments
>   (the return value will be used), a variable (its value will be used)
>   or a list (it will be ‘eval’ed and the return value will be used). The
>   functions and sexps are called/‘eval’ed in the message buffer that is
>   being set up. The headers of the current article are available through
>   the ‘message-reply-headers’ variable, which is a vector of the
>   following headers: number subject from date id references chars lines
>   xref extra.

I think it's just wrong -- I don't think this has ever been possible.

message-mode makes message-reply-headers buffer-local, and
message-reply-headers is then set afterwards, which is logical.  But the
Gnus posting styles is called from message-mode-hook, and the variable
is nil at this point.

So I've just removed the faulty documentation -- you can't use the
message stuff here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no