bug#8674: [RESOLVED: modifying (group ...) setting in (gnus-add-configuration ...) function] [Was: Re: [status update on associated STARTTLS bug] Re: bug#8674: 23.3; Face header rendering bug in Gnus v5.13 on GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) on Windows XP Professional, Service Pack 3]

[Benjamin L. Russell]

The previous issue in modifying the (group ...) setting in the 
(gnus-add-configuration ...) function in ~/.gnus.el (issue #3) has been 
resolved, as follows:

> 3. How to modifying the (group ...) setting in the
> (gnus-add-configuration ...) function) in the ~/.gnus.el
> configuration file so that the change takes effect even if
> the maximum length of a group listed in the buffer exceeds
> the specified group buffer layout width.

(Typo correction; the above issue description should have read as follows:

> 3. How to modify the (group ...) setting in the
> (gnus-add-configuration ...) function in the ~/.gnus.el
> configuration file so that the change takes effect even if
> the maximum length of a group listed in the buffer exceeds
> the specified group buffer layout width.)

Apparently, upgrading to from GNU Emacs 23.2.1 to version 23.3.1 has resolved 
the issue; the group buffer layout width specification using the (group ...) 
setting in the (gnus-add-configuration ...) function in the ~/.gnus.el file 
works correctly.  (I'm not sure what was causing the problem earlier.)

This solution leaves only the following issue:

> 2. How to specify multiple NNTP servers in the ~/.gnus.el
> configuration file?

I'll send an update if there is any progress on issue #2 above.  Again, please 
let me know if you have any suggestions (or any solutions).

-- Benjamin L. Russell

--- On Tue, 5/17/11, Benjamin L. Russell <dekudekuplex@yahoo.com> wrote:

> From: Benjamin L. Russell <dekudekuplex@yahoo.com>
> Subject: [status update on associated STARTTLS bug] Re: bug#8674: 23.3; Face 
> header rendering bug in Gnus v5.13 on GNU Emacs 23.3.1 
> (i386-mingw-nt5.1.2600) on Windows XP Professional, Service Pack 3
> To: "Glenn Morris" <rgm@gnu.org>
> Cc: 8674@debbugs.gnu.org
> Date: Tuesday, May 17, 2011, 10:38 AM
> The previous STARTTLS-related bug has
> been resolved, as follows:
> 
> > 1. [Possible Bug] In Gnus v5.13, for some reason,
> just
> > after sending an NNTP post using C-c C-c, occasionally
> (once
> > in every two to three attempts), Gnus freezes when
> using
> > STARTTLS, just before requesting my SMTP password,
> and
> > refuses to respond until I press C-g.  Here is
> the
> > corresponding transcript from my *Messages* buffer:
> > 
> > [...]
> > 
> > My folder setup under c:\Emacs is as follows:
> > 
> > C:\emacs\.emacs.d
> > C:\emacs\Deprecated Versions
> > C:\emacs\emacs-23.1
> > C:\emacs\emacs-23.2
> > C:\emacs\emacs-23.3
> > 
> > My USER $HOME environmental variable points to
> C:\home,
> > where I have my .emacs and .gnus.el files, among
> others. 
> > 
> > The reason that source file
> > `c:/emacs/emacs-23.2/lisp/gnus/starttls.el' is newer
> than
> > the byte-compiled file is that I manually edited it
> to
> > follow the following directions by Uday Reddy on
> 2010-04-26
> > on "Question #108267 : Questions : VM" (see 
> > https://answers.launchpad.net/vm/+question/108267):
> > 
> > > 1. Added:
> > > (defcustom starttls-kill-program
> > "c:\\cygwin\\bin\\kill"
> > >   "External kill command to send
> > SIGALRM to starttls."
> > >   :group 'starttls)
> > > 
> > > 2. Replaced all three instances of:
> > > (signal-process (process-id process) 'SIGALRM)
> > > with
> > > (call-process starttls-kill-program nil nil nil
> > >           
>    
> >               
> 
> >     "-ALRM" (format "%d"
> (process-id process)))
> > 
> > Is this the correct procedure?
> 
> Apparently not.  When I moved the C:\emacs\emacs-23.1
> and C:\emacs\emacs-23.2 subdirectories into the
> C:\emacs\Deprecated Versions subdirectory and reran
> C:\emacs\emacs-23.3\bin\addpm.exe (effectively restoring the
> original version of
> C:\emacs\emacs-23.3\lisp\gnus\starttls.el), the following
> error message disappeared:
> 
> > `c:/emacs/emacs-23.2/lisp/gnus/starttls.el' newer
> than
> > byte-compiled file
> 
> As stated above, this error message no longer appears.
> 
> Furthermore, Gnus invoked the STARTTLS protocol correctly
> for three consecutive attempts.  Therefore, this
> particular problem has apparently been solved. 
> Accordingly, the `c:/emacs/emacs-23.3/lisp/gnus/starttls.el'
> file should NOT be modified.
> 
> However, the other two issues described in my previous
> message remain, as follows:
> 
> 2. How to specify multiple NNTP servers in the ~/.gnus.el
> configuration file?
> 
> 3. How to modifying the (group ...) setting in the
> (gnus-add-configuration ...) function) in the ~/.gnus.el
> configuration file so that the change takes effect even if
> the maximum length of a group listed in the buffer exceeds
> the specified group buffer layout width.
> 
> I'll send an update if there is any progress on either
> issue #2 or issue #3 above.  Please let me know if you
> have any suggestions (or solutions).
> 
> -- Benjamin L. Russell
> 
> --- On Tue, 5/17/11, Benjamin L. Russell <dekudekuplex@yahoo.com>
> wrote:
> 
> > From: Benjamin L. Russell <dekudekuplex@yahoo.com>
> > Subject: Re: bug#8674: 23.3; Face header rendering bug
> in Gnus v5.13 on GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) on
> Windows XP Professional, Service Pack 3
> > To: "Glenn Morris" <rgm@gnu.org>
> > Cc: 8674@debbugs.gnu.org
> > Date: Tuesday, May 17, 2011, 8:11 AM
> > > The Gnus manual says
> > > 
> > >    Viewing an [sic] `Face' header requires
> > > an Emacs that is able to
> > >    display PNG images.
> > > 
> > > Can your Emacs display PNG images?
> > > If not, I imagine this is the same as
> > > 
> > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8324
> > 
> > It cannot; however, when I following your link,
> downloaded
> > the libpng 1.4.3 package from "GTK+ - Download for
> Windows"
> > (see http://www.gtk.org/download-windows.html), unzipped
> the
> > libpng_1.4.3-1_win32.zip archive, copied the
> > ..\libpng_1.4.3-1_win32\bin\libpng14-14.dll file into
> both
> > the C:\WINDOWS\system32 and C:\emacs\emacs-23.3\bin
> > directories, and restarted Emacs 23.3.1, Emacs was
> able to
> > read PNG files correctly.
> > 
> > Subsequently reading a USENET message with a Face
> header
> > via NNTP in Gnus then caused the Face header to be
> rendered
> > correctly in the "From" line.
> > 
> > Bug solved!
> > 
> > Incidentally, I also have three other problems with
> > Emacs-23.3.1 (one is a possible bug, and the other two
> are
> > possible lack of features), as follows:
> > 
> > 1. [Possible Bug] In Gnus v5.13, for some reason,
> just
> > after sending an NNTP post using C-c C-c, occasionally
> (once
> > in every two to three attempts), Gnus freezes when
> using
> > STARTTLS, just before requesting my SMTP password,
> and
> > refuses to respond until I press C-g.  Here is the
> > corresponding transcript from my *Messages* buffer:
> > 
> > > Sending...
> > > You have lines longer than 79 characters. 
> Really
> > post? (y or n) 
> > > Sending news via news20.forteinc.com using
> nntp...
> > > Sending via mail...
> > > Source file
> > `c:/emacs/emacs-23.2/lisp/gnus/starttls.el' newer
> than
> > byte-compiled file
> > > Opening STARTTLS connection to
> > `plus.smtp.mail.yahoo.com:587'...done
> > > Quit
> > 
> > For some reason, Emacs still references
> > `c:/emacs/emacs-23.2/lisp/gnus/starttls.el' (the
> version for
> > Emacs 23.2.1) instead of
> > `c:/emacs/emacs-23.3/lisp/gnus/starttls.el' (the
> version for
> > Emacs 23.3.1) (still unmodified), even though I just
> ran
> > C:\emacs\emacs-23.3\bin\addpm.exe.
> > 
> > My folder setup under c:\Emacs is as follows:
> > 
> > C:\emacs\.emacs.d
> > C:\emacs\Deprecated Versions
> > C:\emacs\emacs-23.1
> > C:\emacs\emacs-23.2
> > C:\emacs\emacs-23.3
> > 
> > My USER $HOME environmental variable points to
> C:\home,
> > where I have my .emacs and .gnus.el files, among
> others. 
> > 
> > The reason that source file
> > `c:/emacs/emacs-23.2/lisp/gnus/starttls.el' is newer
> than
> > the byte-compiled file is that I manually edited it
> to
> > follow the following directions by Uday Reddy on
> 2010-04-26
> > on "Question #108267 : Questions : VM" (see 
> > https://answers.launchpad.net/vm/+question/108267):
> > 
> > > 1. Added:
> > > (defcustom starttls-kill-program
> > "c:\\cygwin\\bin\\kill"
> > >   "External kill command to send
> > SIGALRM to starttls."
> > >   :group 'starttls)
> > > 
> > > 2. Replaced all three instances of:
> > > (signal-process (process-id process) 'SIGALRM)
> > > with
> > > (call-process starttls-kill-program nil nil nil
> > >               
> >                
> >     "-ALRM" (format "%d" (process-id process)))
> > 
> > Is this the correct procedure?
> > 
> > 2. [Possible Lack of a Feature] I wish to specify
> multiple
> > NNTP servers in my .gnus.el file, but don't know how
> to do
> > so.  The relevant portion from my ~/.gnus.el file is
> as
> > follows:
> > 
> > > (setq gnus-select-method '(nntp
> > "news20.forteinc.com"))
> > 
> > > (add-to-list 'gnus-secondary-select-methods
> '(nntp
> > "news.gmane.org"))
> > 
> > > (add-to-list 'gnus-secondary-select-methods
> '(nntp
> > "news.gnus.org"))
> > 
> > The relevant portion from my ~/.authinfo file is as
> > follows:
> > 
> > > machine news20.forteinc.com login
> <username>
> > password <password>
> > 
> > The <username> and <password> portions
> have
> > been substituted with the appropriate information
> > accordingly.
> > 
> > For some reason, the second invocation of
> (add-to-list
> > 'gnus-secondary-select-methods '(...)) seems to be
> ignored.
> > 
> > Do you know how to specify a third NNTP server in my
> > ~/.gnus.el file?
> > 
> > 3. [Possible Lack of a Feature] For some reason, I am
> > unable to specify a width for the group buffer that is
> less
> > than the width of the maximum-length group name in
> Gnus when
> > displaying a customized view with groups in the
> upper-left
> > buffer, articles in the upper-right buffer, and
> article
> > bodies in the lower buffer in my ~/.gnus.el file. 
> Here
> > is the relevant code:
> > 
> > > ;; The following section controls the layout
> after
> > displaying the article buffer
> > > ; change the configuration of a single buffer
> setting,
> > without using the complicated
> gnus-buffer-configuration
> > variable (see "Frequently Asked Questions: Window
> Layout" at
> > http://gnus.org/manual/gnus_295.html)
> > > (gnus-add-configuration
> > >  ; configure the article buffer
> > >  '(article
> > >    ; split the screen in two vertically, and
> > use the following settings for the upper half of the
> window
> > >    (vertical 1.0
> > >          ; the
> > original number of rows for the group + summary
> buffers
> > together, copied from "Frequently Asked Questions: FAQ
> 4 -
> > Reading messages" (http://www.gnus.org/manual/gnus_400.html#SEC473)
> > > ;     
> >    (horizontal 28
> > >          ; setting
> > of the number of rows for the group + summary buffers
> > together, adapted for my borrowed laptop PC from JIII
> > >      
> >    (horizontal 20
> > >        
> >      ; the original number of
> > columns for the group buffer width setting, copied
> from
> > "Frequently Asked Questions: FAQ 4 - Reading messages"
> (http://www.gnus.org/manual/gnus_400.html#SEC473)
> > > ;           
> >      (group 50)
> > >        
> >      ; setting of the number of
> > columns for the group buffer width setting to match
> my
> > settings in Forte' Agent 5.0
> > > ;       
> >      (group 53)
> > >        
> >      ; setting of the number of
> > columns for the group buffer width setting to display
> all
> > newsgroup names without truncation
> > > ;           
> >      (group 77)
> > >        
> >      ; setting of the number of
> > columns for the group buffer width setting to
> distinguish
> > all newsgroup names uniquely
> > >        
> >      (group 69)
> > >        
> >      ; let the summary buffer take
> > the remainder of the width of the rows, and position
> the
> > point (cursor) therein
> > >        
> >          (summary
> > 1.0 point) )
> > >          ; let the
> > lower half take up the remainder of the horizontal
> space,
> > and apply the following settings therein
> > >      
> >    (horizontal 1.0
> > >        
> >      ; let the article buffer take
> > up the entire space of the lower half of the window
> > >        
> >          (article
> > 1.0)))))
> > 
> > In the above code, the modification from (group 77)
> to
> > (group 69) had no effect.  Further reducing the
> setting
> > to (group 50) had no effect, either.  In a previous
> > version of Emacs on Windows XP, Service Pack 3,
> installed in
> > circa November 2007, on which I had installed Gnus in
> circa
> > May of 2009 (that computer has since been reformatted,
> so I
> > do not have the version information available), the
> settings
> > worked fine.  How can I make the (group ...) setting
> > modification effective?
> > 
> > Solutions to the above problems in using Gnus v5.13 on
> GNU
> > Emacs 23.3.1 would help enormously.
> > 
> > Thank you for your assistance!
> > 
> > Sincerely yours,
> > 
> > Benjamin L. Russell
> > 
> > --- On Tue, 5/17/11, Glenn Morris <rgm@gnu.org>
> > wrote:
> > 
> > > From: Glenn Morris <rgm@gnu.org>
> > > Subject: Re: bug#8674: 23.3; Face header
> rendering bug
> > in Gnus v5.13 on GNU Emacs 23.3.1
> (i386-mingw-nt5.1.2600) on
> > Windows XP Professional, Service Pack 3
> > > To: "Benjamin L. Russell" <DekuDekuplex@Yahoo.com>
> > > Cc: 8674@debbugs.gnu.org
> > > Date: Tuesday, May 17, 2011, 6:43 AM
> > > Benjamin L. Russell wrote:
> > > 
> > > > There is a bug in GNU Emacs 23.3.1 that
> prevents
> > > correct rendering of
> > > > Face headers in NNTP postings. 
> Specifically,
> > the
> > > following Emacs Lisp
> > > > code in my ~/.gnus.el file for inserting a
> face
> > header
> > > in a USENET
> > > > posting works on GNU Emacs 23.2.1, but not
> on
> > version
> > > 23.3.1, with Gnus
> > > > v5.13:
> > > 
> > > The Gnus manual says
> > > 
> > >    Viewing an [sic] `Face' header requires
> > > an Emacs that is able to
> > >    display PNG images.
> > > 
> > > Can your Emacs display PNG images?
> > > If not, I imagine this is the same as
> > > 
> > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8324
> > >
> >
>