Re: documentation of gnus-article-treat-dumbquotes outdated?

[Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>]

Hi Reiner,


Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
> I understand that this works (as long as "un-/mis-labeled" doesn't
> include other charsets).  Could you elaborate what you suggest WRT
> the documentation of gnus-article-treat-dumbquotes?

Sorry, this was more of a drive-by response.  I had solved the
underlying issue in a different way than gnus-article-treat-dumbquotes
or the solution in that discussion that I mentioned which was actually
about rmail.

I think that somehow patching/washing Latin-1 text is not an adequate
solution, when what we have is actually a problem of mis-labeling.
Correcting the label seems the right solution to me.

After that of course comes the separate question of how to represent
the result.  If you are on a latin-1-only text terminal or you don't
have the fonts, you would need to represent the characters involved
by approximation, e.g. by using the display table. 

In effect, if it was just me, I'd devise a solution along those lines
and deprecate things like gnus-article-treat-dumbquotes altogether.
Your mentioning of `1 g windows-1252 RET' goes into the same
direction.

This could be simplyfied if we had a customizable variable that has a
selection of language environments and that sets the variables
gnus-newsgroup-ignored-charsets and gnus-default-charset accordingly.
Or it could even be automatic with setting gnus-default-charset.
I.e. when I do (setq gnus-default-charset 'windows-1252), us-ascii and
iso-8859-1 could be added to gnus-newsgroup-ignored-charsets
automatically.


> Could you elaborate what you suggest WRT the documentation of
> gnus-article-treat-dumbquotes?

On a more "constructive" note:

> - What does "unilateral extension to the character map" mean?  Which
> character map?  Latin1 (= iso-8859-1)?

That's what it does, see gnus-article-dumbquotes-map. 

> - I guess most (or all?) chars from `gnus-article-dumbquotes-map'
> are `windows-1252' characters, not present in Latin-1.

Actually my version of gnus-article-dumbquotes-map (Gnus 5.10.1) also
includes "\264" (replacing it with "'") which is a regular Latin-1
character, I believe.  Not sure why, possibly for symmetry.

> - A better alternative to `W d' in the development version of Emacs
> (CVS HEAD) is `1 g windows-1252 RET' after `(require "code-pages")'.
> Should we mentions this?

> ,----[ (info "(gnus)Article Washing") ]
> | `W d'
> |      Treat M****s*** sm*rtq**t*s according to
> |      `gnus-article-dumbquotes-map' (`gnus-article-treat-dumbquotes').
> |      Note that this function guesses whether a character is a
> |      sm*rtq**t* or not, so it should only be used interactively.
> | 
> |      Sm*rtq**t*s are M****s***'s unilateral extension to the character
> |      map in an attempt to provide more quoting characters.  If you see
> |      something like `\222' or `\264' where you're expecting some kind of
> |      apostrophe or quotation mark, then try this wash.
> `----

How about:

  Replace characters in the article according to
  `gnus-article-dumbquotes-map' (`gnus-article-treat-dumbquotes').

  This function is intended for articles that show `\222' or `\264'
  where you're expecting some kind of apostrophe or quotation mark, or
  `\264' where you expect a Euro sign or similar breakage.

  Using the default settings for `gnus-article-dumbquotes-map' the
  function will replace characters from Microsoft's extension to the
  ISO-8859-1 charset with ASCII characters.  This means e.g. that
  curly-quote characters will be replaced with ASCII quotes and the
  Euro sign will be replaced with the string "EUR".

  Note that on displays that support it, `1 g windows-1252 RET' (as a
  one-shot) or customizing `gnus-default-charset' to `windows-1252'
  (as a permanent solution) is a better way of handling the problem.

I'm probably not fully adhering to the rules for Emacs documentation
strings here ;-).  The last sentence assumes the implementation I
mention above.  I'm not sure how and when to mention (require
'code-pages).  Ideally code-pages.el should be autoloaded or preloaded
IMO.  I hope that the extension for other language environments is
obvious to a user, otherwise that topic should probably be expanded in
the info docs.


benny