Subject field in summary buffer modified

Subject field in summary buffer modified

[Adam Sjøgren]

Sometimes the subject shown in the summary buffer has the beginning cut
off, i.e. an article with:

  Subject: BC Camplight: How To Die In The North [3/6]

will show this in the summary:

   [   2: unknown                ] How To Die In The North [3/6]

It does not happen all the time, though, because a subject like this:

  Subject: Télé Rouge: Transformation [4/6]

is shown as:

   [   2: unknown                ] Télé Rouge: Transformation [4/6]

(I'm guessing there is something about non-ascii chars going on.)

I can't for the life if me figure out if this is something I have
configured, and forgotten about, or if it is a default behaviour that I
need to find out how to suppress.

Any hints are very welcome!


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Subject field in summary buffer modified

[Lars Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Sometimes the subject shown in the summary buffer has the beginning cut
> off, i.e. an article with:
>
>   Subject: BC Camplight: How To Die In The North [3/6]
>
> will show this in the summary:
>
>    [   2: unknown                ] How To Die In The North [3/6]
>
> It does not happen all the time, though, because a subject like this:
>
>   Subject: Télé Rouge: Transformation [4/6]
>
> is shown as:
>
>    [   2: unknown                ] Télé Rouge: Transformation [4/6]

Hm.  Could the backend be outputting different data in the headers view
than in the article data?

> I can't for the life if me figure out if this is something I have
> configured, and forgotten about, or if it is a default behaviour that I
> need to find out how to suppress.

Look in your .gnus file for ":"?  :-)

It could be...  er...  `gnus-simplify-subject-functions', perhaps?  Or
`gnus-simplify-ignored-prefixes'.

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

Re: Subject field in summary buffer modified

[Adam Sjøgren]

Lars writes:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>>   Subject: BC Camplight: How To Die In The North [3/6]

>>    [   2: unknown                ] How To Die In The North [3/6]

> Hm. Could the backend be outputting different data in the headers view
> than in the article data?

Good question. I guess you mean the nntp-backend, not gwene.org, right?

>> I can't for the life if me figure out if this is something I have
>> configured, and forgotten about, or if it is a default behaviour that I
>> need to find out how to suppress.

> Look in your .gnus file for ":"?  :-)

I have poured over my config - I even removed the old stuff I had in
gnus-list-identifiers, gnus-simplify-subject-functions,
gnus-simplify-subject-fuzzy-regexp, and checked that
message-subject-re-regexp is not the culprit...

,----[ C-h v message-subject-re-regexp RET ]
| message-subject-re-regexp is a variable defined in `message.el'.
| Its value is
| "^[ 	]*\\([RrSs][EeVv]\\(\\[[0-9]*\\]\\)*:[ 	]*\\)*[ 	]*"
| Original value was 
| "^[ 	]*\\([Rr][Ee]\\(\\[[0-9]*\\]\\)*:[ 	]*\\)*[ 	]*"
| 
| Documentation:
| *Regexp matching "Re: " in the subject line.
`----

> It could be...  er...  `gnus-simplify-subject-functions', perhaps?  Or
> `gnus-simplify-ignored-prefixes'.

Let me see... Well, they are both nil :-/


  Best regards,

    Adam

-- 
 "Subdued flamboyance"                                        Adam Sjøgren
                                                         asjo@koldfront.dk


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Subject field in summary buffer modified

[Adam Sjøgren]

Adam writes:

>> It could be...  er...  `gnus-simplify-subject-functions', perhaps?  Or
>> `gnus-simplify-ignored-prefixes'.

> Let me see... Well, they are both nil :-/

Here is an article that exhibits the problem in Gnus for me:

  news.gmane.org gwene.dk.gaffa.anmeldelser.cd:106

Hm. Let me just ngrep what happens when I read it, to see what comes
over the wire..

Oh. Encryption. Great.

Ok, let me telnet:

  $ telnet news.gwene.org nntp
  Trying 80.91.229.13...
  Connected to news.gwene.org.
  Escape character is '^]'.
  200 news.gmane.org InterNetNews NNRP server INN 2.5.1 ready (posting ok)
  group gwene.dk.gaffa.anmeldelser.cd
  211 107 1 107 gwene.dk.gaffa.anmeldelser.cd
  article 106
  220 106 <x1-uNZ7JGyTNme0mVkrfXTsQk2zjXE@gwene.org> article
  [...]
  Subject: Mindi Abair: Wild Heart [4/6]
  [...]
  .
  xover 106-106
  224 Overview information for 106-106 follows
  106     Mindi Abair: Wild Heart [4/6]   unknown <post@gwene.org>        Tue, 27 Jan 2015 08:00:00 +0100 <x1-uNZ7JGyTNme0mVkrfXTsQk2zjXE@gwene.org>                999     2       Xref: news.gmane.org gwene.dk.gaffa.anmeldelser.cd:106
  .
  quit
  205 Bye!
  Connection closed by foreign host.
  $ 

This makes me think that it is Gnus doing this. Hm.

Can I find the right function to edebug? Ok, found it - by trial and error:

 gnus-summary-remove-list-identifiers

is the culprit. It removes "^[A-Z ]*?: " (!)

My elisp fu fails me now, this function:

  (defun gnus-group-get-list-identifiers (group)
    "Get list identifier regexp for GROUP."
    (or (gnus-parameter-list-identifier group)
        (if (consp gnus-list-identifiers)
            (mapconcat 'identity gnus-list-identifiers " *\\|")
          gnus-list-identifiers)))

returns "^[A-Z ]*?: " even though gnus-list-identifiers is nil?!?

Something is setting gnus-list-identifiers behind my back locally, somehow?!

Because if I run: (gnus-group-get-list-identifiers
"nntp+news.gwene.org:gwene.dk.gaffa.anmeldelser.cd") directly, it
returns nil, as I expect.

I can't for the life of me figure out how that happens, when I edebug
the function and do C-h v on gnus-list-identifers, I'm told it is nil.

But edebugging I can see that consp returns t and the function returns
"^[A-Z ]*?: ".

If I change it to:

  (defun gnus-group-get-list-identifiers (group)
    "Get list identifier regexp for GROUP."
    nil)

The summary looks as I expected it to do, nothing removed.

Ok, elisp experts - enlighten me!


  Best regards,

    Adam

-- 
 "Har du computer, som starter op i DOS, så' det:             Adam Sjøgren
  *blah* *blah* Adios amigos!"                           asjo@koldfront.dk


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Subject field in summary buffer modified

[Lars Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> My elisp fu fails me now, this function:
>
>   (defun gnus-group-get-list-identifiers (group)
>     "Get list identifier regexp for GROUP."
>     (or (gnus-parameter-list-identifier group)
>         (if (consp gnus-list-identifiers)
>             (mapconcat 'identity gnus-list-identifiers " *\\|")
>           gnus-list-identifiers)))
>
> returns "^[A-Z ]*?: " even though gnus-list-identifiers is nil?!?
>
> Something is setting gnus-list-identifiers behind my back locally, somehow?!
>
> Because if I run: (gnus-group-get-list-identifiers
> "nntp+news.gwene.org:gwene.dk.gaffa.anmeldelser.cd") directly, it
> returns nil, as I expect.

Huh.  Uhm...  do you have list-identifiers set for the topic or...
something?  `G p' on the group and the topic it's in, if it's in a
topic...

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

Re: Subject field in summary buffer modified

[Adam Sjøgren]

Lars writes:

> Huh.  Uhm...  do you have list-identifiers set for the topic or...
> something?  `G p' on the group and the topic it's in, if it's in a
> topic...

Ahhh, good catch.

Yes, I had it set in the topic parameters for my "Gwene" topic.

Thanks, it was an error 40 all along... Maybe that will teach me to grep
through .newsrc.eld the next time something "magic" seems to happen.


  Best regards,

    Adam

-- 
 "Melodin kommer från Gud, texten får man göra själv;         Adam Sjøgren
  det er det som är segt."                               asjo@koldfront.dk


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english