[XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Danny Siu]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]


Hi,

I have problem staring Gnus and XEmacs-20.3.  The backtrace is attached.

It seems like "\*\*\* EOOH \*\*\*" is not a valid regexp under XEmacs-20.3.
Both FSF Emacs-20.2 and XEmacs-20.2 have no problem with it.  nndoc.el in
qgnus 0.17 and gnus-5.4.67 are using this regexp to look for the boundary
between messages in babyl mbox format.

I think XEmacs-20.3 supports new Perl-like regexp constructs.  Whould this be
the cause?

-- 
=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Danny Dick-Fung Siu                              mailto:dsiu@adobe.com 
 WebReady Printing Group           mailto:dsiu@alumni.eecs.berkeley.edu 
 Adobe Systems Incorporated          http://www.csua.berkeley.edu/~dsiu 
=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/plain; charset=US-ASCII, Size: 1021 bytes --]


Backtrace:
----------
Signaling: (invalid-regexp "Invalid preceding regular expression")
  looking-at("*** EOOH ***")
  nndoc-babyl-head-begin()
  nndoc-dissect-buffer()
  nndoc-possibly-change-buffer("Submission" "Submission")
  nndoc-close-group("Submission" "Submission")
  gnus-get-unread-articles(nil)
  gnus-setup-news(nil nil nil)
  byte-code("\b¬ˆ	¬… ˆª»ÃÄ!ˆÅ\x0e\x06!\x16\a\x0e\b¬„\x0e	«ƒÊ ˆ\x0e\v«ˆÌ ˆÍÎÏ\"ˆÐÑ\x0e\x12\b#ˆÓ\x0e\x12!ˆÔ ˆÕÖ!ˆ× ˆÃØ!ˆÑ‡" [dont-connect did-connect gnus-group-quit run-hooks gnus-startup-hook gnus-make-newsrc-file gnus-startup-file gnus-current-startup-file gnus-slave gnus-use-dribble-file gnus-dribble-read-file gnus-use-grouplens bbb-login add-hook gnus-summary-mode-hook gnus-grouplens-mode gnus-setup-news nil level gnus-group-list-groups gnus-group-first-unread-group gnus-configure-windows group gnus-group-set-mode-line gnus-started-hook] 4)
  gnus-1(nil nil nil)
  gnus(nil)
  call-interactively(gnus)
  command-execute(gnus t)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Hrvoje Niksic]

Danny Siu <dsiu@Adobe.COM> writes:

> I have problem staring Gnus and XEmacs-20.3.  The backtrace is attached.
> 
> It seems like "\*\*\* EOOH \*\*\*" is not a valid regexp under
> XEmacs-20.3.

`\*\*\* EOOH \*\*\*' is a valid regexp.  However, `*** EOOH ***' is
not valid.  You must quote it properly:

(looking-at "\\*\\*\\* EOOH \\*\\*\\*")

> I think XEmacs-20.3 supports new Perl-like regexp constructs.
> Whould this be the cause?

Yes, that's the cause.  A side-effect of that patch was to reject
things like "**" or "++".  I was never sure *why* this patch had that
side-effect, but I guess we have to live with it now.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it."                                    -- Donald Knuth

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Michael R Cook]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

 Hrvoje> A side-effect of that patch was to reject things like "**"
 Hrvoje> or "++".  I was never sure *why* this patch had that
 Hrvoje> side-effect, but I guess we have to live with it now.

Pre-patch, the regular expressions "a*?" and "a+?" and "a??" were
parsed by the same code that recognized all those
pedantically-correct-but-practially-useless combinations of "*" and
"+" and "?".  For example, "a**+**?*??" was recognized as being the
same as "a*".

When I implemented the new minimal-matching constructs ("a*?" and
"a+?" and "a??"), I would have had to write extra code to continue
to recognize the pcbpu constructs.

Further, the only uses of these pcbpu constructs that I've see were
actually mistakes, like this "\*\*\* EOOH \*\*\*" problem.  (So,
there's an advantage to rejecting them.)

Finally, if we reject constructs like "a**" now, we can more easily
give them useful semantics in the future.

So, that's why.

Michael.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Hrvoje Niksic]

Michael R Cook <mcook@cognex.com> writes:

> Further, the only uses of these pcbpu constructs that I've see were
> actually mistakes, like this "\*\*\* EOOH \*\*\*" problem.  (So,
> there's an advantage to rejecting them.)
> 
> Finally, if we reject constructs like "a**" now, we can more easily
> give them useful semantics in the future.
> 
> So, that's why.

Sounds reasonable.  Did Stallman accept the patch, BTW?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!" 
"They are my innards! I will not have them misread by a poseur!"

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Danny Siu]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Hrvoje Niksic writes:

  Hrvoje> Danny Siu <dsiu@Adobe.COM> writes:
  >> I have problem staring Gnus and XEmacs-20.3.  The backtrace is
  >> attached.
  >>
  >> It seems like "\*\*\* EOOH \*\*\*" is not a valid regexp under
  >> XEmacs-20.3.

  Hrvoje> `\*\*\* EOOH \*\*\*' is a valid regexp.  However, `*** EOOH ***'
  Hrvoje> is not valid.  You must quote it properly:

  Hrvoje> (looking-at "\\*\\*\\* EOOH \\*\\*\\*")

Fixed.  The patch is based on qgnus-0.17.  Lars, can you put it into 0.18?

  >> I think XEmacs-20.3 supports new Perl-like regexp constructs.  Whould
  >> this be the cause?

  Hrvoje> Yes, that's the cause.  A side-effect of that patch was to reject
  Hrvoje> things like "**" or "++".  I was never sure *why* this patch had
  Hrvoje> that side-effect, but I guess we have to live with it now.

  Hrvoje> -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb,
  Hrvoje> Croatia
  Hrvoje> --------------------------------+--------------------------------
  Hrvoje> "Beware of bugs in the above code; I have only proved it correct,
  Hrvoje> not tried it."  -- Donald Knuth

-- 
=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Danny Dick-Fung Siu                              mailto:dsiu@adobe.com 
 WebReady Printing Group           mailto:dsiu@alumni.eecs.berkeley.edu 
 Adobe Systems Incorporated          http://www.csua.berkeley.edu/~dsiu 
=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[-- Attachment #2: nndoc-regexp-fix.patch --]
[-- Type: application/octet-stream, Size: 2212 bytes --]

diff -C5 lisp/ChangeLog lisp-new/ChangeLog
*** lisp/ChangeLog	Wed Nov 26 08:45:49 1997
--- lisp-new/ChangeLog	Fri Dec  5 15:17:35 1997
***************
*** 1,5 ****
--- 1,11 ----
+ Fri Dec  5 15:15:05 1997  Danny Siu  <dsiu@adobe.com>
+ 
+ 	* nndoc.el (nndoc-babyl-body-begin): quote the regexp for the
+  	string "*** EOOH ***" properly.
+ 	(nndoc-babyl-head-begin): Same as above.
+ 
  Wed Nov 26 17:40:57 1997  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>
  
  	* gnus.el: Quassia Gnus v0.17 is released.
  
  Wed Nov 26 16:04:25 1997  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>
diff -C5 lisp/nndoc.el lisp-new/nndoc.el
*** lisp/nndoc.el	Mon Nov 24 07:02:32 1997
--- lisp-new/nndoc.el	Fri Dec  5 15:14:23 1997
***************
*** 388,398 ****
    (when (re-search-forward "\^_\^L *\n" nil t)
      t))
  
  (defun nndoc-babyl-body-begin ()
    (re-search-forward "^\n" nil t)
!   (when (looking-at "\*\*\* EOOH \*\*\*")
      (let ((next (or (save-excursion
  		      (re-search-forward nndoc-article-begin nil t))
  		    (point-max))))
        (unless (re-search-forward "^\n" next t)
  	(goto-char next)
--- 388,398 ----
    (when (re-search-forward "\^_\^L *\n" nil t)
      t))
  
  (defun nndoc-babyl-body-begin ()
    (re-search-forward "^\n" nil t)
!   (when (looking-at "\\*\\*\\* EOOH \\*\\*\\*")
      (let ((next (or (save-excursion
  		      (re-search-forward nndoc-article-begin nil t))
  		    (point-max))))
        (unless (re-search-forward "^\n" next t)
  	(goto-char next)
***************
*** 400,410 ****
  	(insert "\n")
  	(forward-line -1)))))
  
  (defun nndoc-babyl-head-begin ()
    (when (re-search-forward "^[0-9].*\n" nil t)
!     (when (looking-at "\*\*\* EOOH \*\*\*")
        (forward-line 1))
      t))
  
  (defun nndoc-forward-type-p ()
    (when (and (re-search-forward "^-+ Start of forwarded message -+\n+" nil t)
--- 400,410 ----
  	(insert "\n")
  	(forward-line -1)))))
  
  (defun nndoc-babyl-head-begin ()
    (when (re-search-forward "^[0-9].*\n" nil t)
!     (when (looking-at "\\*\\*\\* EOOH \\*\\*\\*")
        (forward-line 1))
      t))
  
  (defun nndoc-forward-type-p ()
    (when (and (re-search-forward "^-+ Start of forwarded message -+\n+" nil t)

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Michael R Cook]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

 Hrvoje> Sounds reasonable.  Did Stallman accept the patch, BTW?

I think so.  He said he would, but I don't know if he did
for the latest release, or whether he was saving it for later.

Someone who has one of the recent releases could do

  grep RE_NO_MINIMAL_MATCHING regex.c

Michael.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Lars Balker Rasmussen]

Michael R Cook <mcook@cognex.com> writes:
> Someone who has one of the recent releases could do
> 
>   grep RE_NO_MINIMAL_MATCHING regex.c

Not in 20.2  :-/

Am I the only one who considers the current state of affairs emacs-wise
utterly childish?
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Hrvoje Niksic]

Lars Balker Rasmussen <lbr@mjolner.dk> writes:

> Michael R Cook <mcook@cognex.com> writes:
> > Someone who has one of the recent releases could do
> > 
> >   grep RE_NO_MINIMAL_MATCHING regex.c
> 
> Not in 20.2  :-/
> 
> Am I the only one who considers the current state of affairs emacs-wise
> utterly childish?

Huh?  Which affairs do you mean, precisely?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Lars Balker Rasmussen]

Hrvoje Niksic <hniksic@srce.hr> writes:
> Huh?  Which affairs do you mean, precisely?

emacs/mule/xemacs/emacs-19.35/cl-emacs

Of course I'm not at all privy to the discussions and decisions
involved, but from the outside it appear to be more of ego-problems than
technical ones.  Cooperative development indeed.

No offense intended at all.  It's just that as a user, it feels as if I
can't have access to a bunch of features, without installing (and
using!) n copies of "the same program".
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Richard Coleman]

> > Huh?  Which affairs do you mean, precisely?
> 
> emacs/mule/xemacs/emacs-19.35/cl-emacs
> 
> Of course I'm not at all privy to the discussions and decisions
> involved, but from the outside it appear to be more of ego-problems than
> technical ones.  Cooperative development indeed.
> 
> No offense intended at all.  It's just that as a user, it feels as if I
> can't have access to a bunch of features, without installing (and
> using!) n copies of "the same program".

Yes, the (X)Emacs is a huge project.  It is not suprising that
different people will have different views on how development should
proceed.   The freedom of free software does come at a cost (although
I consider this only a small problem).

Besides, only Xemacs and Emacs matter at the moment.  Cl-emacs is
currently vaporware.  And Mule has been subsumed by both Xemacs and
Emacs (although in different ways).

So, just pick one, and stick with it.  They are both damn good.

--
Richard Coleman
coleman@math.gatech.edu

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Kai Grossjohann]

>>>>> On 08 Dec 1997, Lars Balker Rasmussen said:

  Lars> No offense intended at all.  It's just that as a user, it
  Lars> feels as if I can't have access to a bunch of features,
  Lars> without installing (and using!) n copies of "the same
  Lars> program".

Surely the differences between Emacs and XEmacs can only be rather
marginal, from a user's point of view?  I think I would miss a few
niceties when switching from Emacs to XEmacs now [1], and I think my
colleague would miss a few other niceties when switching from XEmacs
to Emacs now [2], but I don't think that this really matters.

[1] Example: mouse-drag and mouse-copy.
[2] Example: x-symbol.

-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Karl Kleinpaste]

Lars Balker Rasmussen <lbr@mjolner.dk> writes:
> emacs/mule/xemacs/emacs-19.35/cl-emacs

Yes, I agree.

> Of course I'm not at all privy to the discussions and decisions
> involved, but from the outside it appear to be more of ego-problems than
> technical ones.

The XEmacs documentation supports that view.

Er, I suppose I must instead say, "used to support."  It seems that,
as of 19.16, the NEWS file for XEmacs has undergone a politically
correct, or perhaps lawyerly correct, revision.  In 19.14, `C-h n'
brings up the NEWS file containing this longish diatribe from Ben Wing
on why fsfmacs and XEmacs seemed doomed never to merge:

   Don't think we're just being needlessly perverse by continuing to have
   XEmacs. I'm well aware of the problems in having a project split, and
   don't think for a minute that we haven't tried (extremely hard, in
   fact) to come up with a merge.
   
   Unfortunately, as I have said before, the odds of this happening are
   quite low due to severe conflicts (both technical, procedural, and
   philosophical) between RMS and the XEmacs developers. If we were to
   assent to even half of what RMS wants in a merged Emacs, it would take
   years of work to produce the merged Emacs, and the result would be
   less powerful than the existing XEmacs.
   
   Since so many people seem so misinformed about this problem, I'll go
   ahead and state the fundamental dividing issues:
   
    1. RMS does not believe in data abstraction, and cannot be convinced
       of the folly of this. This by itself is such a huge division that
       it makes a merge basically unthinkable. Because of this, FSF Emacs
       is basically unmaintainable by anyone other than RMS. RMS has
       consented to all the data abstraction I want provided that I take
       sole responsibility for writing this code (which basically means
       I'd have to write almost all of the code or rewrite most of his
       code), and provided that he can use this issue as a bargaining
       chip to get concessions of his own.
    2. RMS sees the merge process as a series of mutual concessions
       traded back and forth. IMHO this is reasonable for a peace treaty
       but absurd for a piece of software -- we have to have technical
       agreement on the major issues involved, and the chance of that
       happening is basically nil.
    3. RMS has insisted in full backwards compatibility with all aspects
       of FSF Emacs, no matter how ugly; and furthermore, this backwards
       compatibility must work fast enough to make existing code run
       without problem. This basically means that there would have to be
       parallel C implementations of events, keymaps, and many other data
       structures. This not only will take months or years of extra work
       to implement, but poses some fundamental technical problems due to
       the non-abstractedness of FSF Emacs (e.g. in FSF Emacs keymaps are
       conses or vectors and a lot of code depends on this, and
       reconciling this with XEmacs's primitive keymap type is difficult
       to impossible).
    4. RMS will not even consent to neutral names for the two editors. He
       objects to call his editor FSF Emacs because for some unfathomable
       reason he finds it insulting. He suggests just Emacs, which I find
       not only insulting (XEmacs is just as much Emacs as is FSF Emacs)
       but also quite confusing. He will not even consent to calling his
       editor GNU Emacs without also referring to XEmacs as GNU XEmacs --
       basically a Borg-like assimilation attempt at making XEmacs a GNU
       product, which it is not. (None of the developers of Lucid Emacs
       and XEmacs were or are sanctioned by GNU, and none of us got the
       least bit of assistance or cooperation in doing our work. In fact,
       RMS actively made it harder by choosing to ignore all work
       previously done in XEmacs and adding his own incompatible
       interfaces for functionality already in XEmacs. This makes it
       quite difficult to track FSF Emacs and keep a sane API.) He has
       stated many times, and continues to assert, that most or all of
       the work done on Lucid Emacs and XEmacs was done primarily as a
       testing ground for potential features to be added to FSF Emacs.
       All of the developers of Lucid Emacs and XEmacs assert that this
       is patently false -- so why does RMS continue to insist that this
       is the case?

In other words, it's all attitude.

--karl

Emacs vs Xemacs (was: Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el)

[Per Abrahamsen]

Karl Kleinpaste <karl@jprc.com> writes:

> Er, I suppose I must instead say, "used to support."  It seems that,
> as of 19.16, the NEWS file for XEmacs has undergone a politically
> correct, or perhaps lawyerly correct, revision.  In 19.14, `C-h n'

The attitude has changed as well.  

But this is the wrong forum for such a discussion.  
Try alt.religion.emacs.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Steinar Bang]

>>>>> Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de>:

> Surely the differences between Emacs and XEmacs can only be rather
> marginal, from a user's point of view?  

Hm.  Can MULE-less Xemacs 20.3 and GNU emacs 19.34 run the same byte
compiled programs?

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[Hrvoje Niksic]

Karl Kleinpaste <karl@jprc.com> writes:

> Er, I suppose I must instead say, "used to support."  It seems that,
> as of 19.16, the NEWS file for XEmacs has undergone a politically
> correct, or perhaps lawyerly correct, revision.  In 19.14, `C-h n'
> brings up the NEWS file containing this longish diatribe from Ben Wing
> on why fsfmacs and XEmacs seemed doomed never to merge:

Ben's post was lovely, but it was taken wrongly by many people, so it
was replaced for a politically correct blurb.  With the current
maintainer teams, there are two reasons why XEmacs and FSFmacs will
never merge:

1) Copyright assignments.

Major parts of XEmacs have not been assigned to the FSF (although they 
are GPL-ed), and their authors do not plan to assign them.  Not
requiring legal papers at gunpoint has been XEmacs' policy from time
immemorial, and changing it to require them strictly would piss off a
lot of people who contribute.

2) The matter of control.

Richard Stallman controls FSF Emacs with an iron fist.  He can and
does accept or deny a feature simply because he does or does not
"like" it, often with too little sense for the user base.  The
uncounted examples have proven this, including but not limited to
Ange-ftp fiasco in v19 and MULE fiasco in v20 FSFmacs.  The infamous
matter of "Croatian" language probably falls to the same category.

Even if, by some magic, the Emacsen merged right now, they would
probably split up again immediately, because Stallman would step on
someone.  Hard.

Which brings us to an optional third reason:

3) The matter of hurt feelings.

Finally, many of the people who were hurt by Stallman before simply
don't want to have anything with him.  When I contacted that person,
the first thing he asked me when he found I helped maintain XEmacs was
to stop working on it, because it "hurts the GNU project."  I find it
impossible to cooperate with him on that basis -- but that's just me.


I am now committing a cardinal sin by mailing this message to a
totally unappropriate group, and I beg for forgiveness.  I also beg
for all the responses to go to me privately, where I'll be happy to
discuss XEmacs and stuff with anyone who cares.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

Re: [XEmacs-20.3/Gnus] invalid regexp in nndoc.el

[SL Baur]

Steinar Bang <sb@metis.no> writes:

>>>>>> Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de>:
>> Surely the differences between Emacs and XEmacs can only be rather
>> marginal, from a user's point of view?  

> Hm.  Can MULE-less Xemacs 20.3 and GNU emacs 19.34 run the same byte
> compiled programs?

Yes.  Either bytecompile with Emacs 19.34 or turn on emacs19 compatibility
when bytecompiling with XEmacs 20.3 (noMule should always work, Mule will
work if the lisp source contains only ASCII characters).

Something like

xemacs-20.3 -vanilla -batch \
	-eval '(setq byte-compile-emacs19-compatibility t)' \
	-f batch-byte-compile *.el

will do it from the command line, or put the setq into a site-start.el
file.