Tetris trademark

Tetris trademark

[Chip Coldwell]

Is anybody concerned that lisp/play/tetris.el might be a trademark
infringement?

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426

Re: Tetris trademark

[Richard Stallman]

    Is anybody concerned that lisp/play/tetris.el might be a trademark
    infringement?

File names and function names usually do not raise a trademark issue.
So there is no need to worry about this.

Re: Tetris trademark

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     Is anybody concerned that lisp/play/tetris.el might be a trademark
>     infringement?
>
> File names and function names usually do not raise a trademark issue.
> So there is no need to worry about this.

But what about the game itself?  It's not just the name of the file
and functions, but the Tetris game itself is "subject to the
registered copyrights of Tetris Holding LLC" (according to
http://www.tetris.com/).

Incidentally, I just tried running M-x tetris RET.  After playing 2
games, a buffer appeared called 'tetris-scores' showing 3 scores:

03037   Sat Jan 27 13:48:27 2007       <x@SERVER>
03031   Sat Jan 27 13:48:27 2007        <x@SERVER>
00349   Sat Jan 27 13:34:52 2007         <x@SERVER>

The top 2 scores appear to be from the same game.

Re: Tetris trademark

[Alfred M. Szmidt]

   Incidentally, I just tried running M-x tetris RET.  After playing 2
   games, a buffer appeared called 'tetris-scores' showing 3 scores:

   03037   Sat Jan 27 13:48:27 2007       <x@SERVER>
   03031   Sat Jan 27 13:48:27 2007        <x@SERVER>
   00349   Sat Jan 27 13:34:52 2007         <x@SERVER>

   The top 2 scores appear to be from the same game.

I just tried the same (Emacs CVS 2007-01-26) and got this in my
tetris-scores buffer after one game:

63 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007
-614138055 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007

and if one plays tetris a couple more times:

1750381103 1113788831 1116002824 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:15 2007
1651340622 860783243 614547649 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007
1104386408 689079491 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:27 2007
409625960 1484573134 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:24 2007
302668443 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:30 2007
69 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:30 2007
-1187299218 590383859 1116002819 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:24 2007
-1346613921 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:27 2007
-1663317747 1828060044 614138055 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007
-1806042514 2146540447 994984561 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:15 2007

Re: Tetris trademark

[Chris Moore]

On 1/27/07, Alfred M. Szmidt <ams@gnu.org> wrote:

> 63 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007
> -614138055 ams Alfred M. Szmidt <ams@gnu.org>  Sat Jan 27 14:33:01 2007

I just managed to get a NUL character in my highscore table:

0039^@	Sat Jan 27 23:20:41 2007	 <chris@TRPASLIK>
00388	Sat Jan 27 23:20:41 2007	 <chris@TRPASLIK>
00170	Sat Jan 27 22:33:48 2007	 <chris@TRPASLIK>
00165	Sat Jan 27 22:33:43 2007	 <chris@TRPASLIK>
00096	Sat Jan 27 22:31:38 2007	 <chris@TRPASLIK>
00090	Sat Jan 27 22:30:35 2007	 <chris@TRPASLIK>

and an error message:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  aref(nil 0)
  (put-text-property (1- (point)) (point) (quote face) (aref gamegrid-face-
  (if (eq gamegrid-display-mode (quote glyph)) (add-text-properties (1- ...
  gamegrid-set-face(0)
  (let ((buffer-read-only nil)) (goto-char (gamegrid-cell-offset x y)) (del
  (save-excursion (let (...) (goto-char ...) (delete-char 1) (insert-char c
  gamegrid-set-cell(3 1 0)
  (if (/= c tetris-blank) (gamegrid-set-cell px py tetris-blank))
  (let ((c ...) (px ...) (py ...)) (if (/= c tetris-blank) (gamegrid-set-ce
  (while (<= x --cl-var--) (let (... ... ...) (if ... ...)) (setq x (+ x 1)
  (let* ((x 0) (--cl-var-- ...)) (while (<= x --cl-var--) (let ... ...) (se
  (catch (quote --cl-block-nil--) (let* (... ...) (while ... ... ...) nil))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let* ... ... nil)))
  (block nil (let* (... ...) (while ... ... ...) nil))
  (loop for x from 0 to (1- (tetris-shape-width)) do (let (... ... ...) (if
  (while (<= y --cl-var--) (loop for x from 0 to (1- ...) do (let ... ...))
  (let* ((y 0) (--cl-var-- ...)) (while (<= y --cl-var--) (loop for x from
  (catch (quote --cl-block-nil--) (let* (... ...) (while ... ... ...) nil))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let* ... ... nil)))
  (block nil (let* (... ...) (while ... ... ...) nil))
  (loop for y from 0 to (1- (tetris-shape-height)) do (loop for x from 0 to
  tetris-erase-shape()
  (let ((hit nil)) (tetris-erase-shape) (while (not hit) (setq tetris-pos-y
  tetris-move-bottom()
  call-interactively(tetris-move-bottom)

This happened after 2 scores had already been added into the highscore
table for that game.  I'm wondering if the timer isn't being stopped
properly and/or quickly enough.  The score is being written using a
(format "%05d ...") call, so that NUL must have been written over the
score at a later point.

The value of buffer-file-name in the above backtrace is "c:/Documents
and Settings/chris/Local Settings/Temp/tetris-scores" so it looks like
the code is trying to manupulate the high score table as if it was a
tetris board.

I didn't mention it before, so:

In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600)
 of 2007-01-21 on LENNART-69DE564
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: CSY
  locale-coding-system: cp1250
  default-enable-multibyte-characters: t

Re: Tetris trademark

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Incidentally, I just tried running M-x tetris RET.  After playing 2
>    games, a buffer appeared called 'tetris-scores' showing 3 scores:

I've checked in a fix.

Re: Tetris trademark

[Alfred M. Szmidt]

   >    Incidentally, I just tried running M-x tetris RET.  After
   >    playing 2 games, a buffer appeared called 'tetris-scores'
   >    showing 3 scores:

   I've checked in a fix.

Thanks.  It only works partially though.  If I have a empty
tetris-scores buffer, then it works fine the first time.  But on
subsequent runs, it continues to inser bogus values.  Also, on the
first run atleast, if you hit space in *Tetris* directly (just hold
keep pressing space after a new game has started until you lose) after
the initial score has been written to tetris-scores, then it will
insert a bogus value.

Re: Tetris trademark

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    Incidentally, I just tried running M-x tetris RET.  After
>    >    playing 2 games, a buffer appeared called 'tetris-scores'
>    >    showing 3 scores:
>
>    I've checked in a fix.
>
> Thanks.  It only works partially though.  If I have a empty
> tetris-scores buffer, then it works fine the first time.  But on
> subsequent runs, it continues to inser bogus values.  Also, on the
> first run atleast, if you hit space in *Tetris* directly (just hold
> keep pressing space after a new game has started until you lose) after
> the initial score has been written to tetris-scores, then it will
> insert a bogus value.

I can't reproduce this.  Did you get the updates to both tetris.el and
gamegrid.el?

Re: Tetris trademark

[Alfred M. Szmidt]

   > Thanks.  It only works partially though.  If I have a empty
   > tetris-scores buffer, then it works fine the first time.  But on
   > subsequent runs, it continues to inser bogus values.  Also, on
   > the first run atleast, if you hit space in *Tetris* directly
   > (just hold keep pressing space after a new game has started until
   > you lose) after the initial score has been written to
   > tetris-scores, then it will insert a bogus value.

   I can't reproduce this.  Did you get the updates to both tetris.el
   and gamegrid.el?

Yeah, I just double checked (even did `make bootstrap').  Though the
later behaviour of just holding space until you lose seems to have
mysteriously vanished.  But subsequent games stil get munged scores.

Re: Tetris trademark

[Chris Moore]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > Thanks.  It only works partially though.  If I have a empty
>    > tetris-scores buffer, then it works fine the first time.  But on
>    > subsequent runs, it continues to inser bogus values.  Also, on
>    > the first run atleast, if you hit space in *Tetris* directly
>    > (just hold keep pressing space after a new game has started until
>    > you lose) after the initial score has been written to
>    > tetris-scores, then it will insert a bogus value.
>
>    I can't reproduce this.  Did you get the updates to both tetris.el
>    and gamegrid.el?
>
> Yeah, I just double checked (even did `make bootstrap').  Though the
> later behaviour of just holding space until you lose seems to have
> mysteriously vanished.  But subsequent games stil get munged scores.

It doesn't fix the bug for me either.

I rebuilt from CVS, which brought in both your changed files, deleted
the old highscore file and played a single game.

At the end of the game I saw a ^@ where a zero should be, and an error
about 'Wrong type argument: arrayp, nil' in the message area:

  http://dooglus.rincevent.net/random/2007-01-29--01-50-11.png

I can get a backtrace if you like, but I expect it's the same as the
last one I posted.

Chris.

Re: Font-lock decides function call is function declaration in C+ +

[Chong Yidong]

Does this bug still exist with latest CVS?  If so, please provide a
simple test case (I couldn't find one in your previous messages).

> Hi, this bug remains[*] and a quick look at the C++ file I am editing shows
> that most of my methods have ended up with this sort of misfontification
> somewhere.  Note that misfontification does not occur during initial
> fontification, only after editing (though not in a way I can replicate).  I
> guess sometimes it thinks function calls are part of a declaration, though it
> doesn't necessarily happen when the preceding statement is a declaration.  In
> one occurrence in my C++ file, the misfontification has occurred immediately
> after a for loop.
>
> Again, I'm asking for help.  I never got a response last time.  What do I need
> to look at to see what is going on?
>
> [*] following my revision 1.18 date: 2006-11-15 16:31:03 fix in cc-fonts.el of
> another unrelated issue in CVS Emacs, Emacs CVS fontifies the below with
> font-lock-variable-name-face, rather than font-lock-function-name-face, which
> may/may not give a pointer to where the problem lies.
>
>     _____________________________________________
>     From:   Marshall, Simon 
>     Sent:   07 September 2006 17:41
>     To:     'bug-cc-mode@gnu.org'
>     Cc:     'emacs-pretest-bug@gnu.org'
>     Subject:        Font-lock decides function call is function declaration in
>     C++
>
>     Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of
>     code of the form:
>
>             foo(bar);
>
>     Or:
>
>             foo() = bar;
>
>     Are function declarations, and puts font-lock-function-name-face on (in
>     these examples) "foo".  It seems to happen when I am editing the line in
>     question, or maybe just on a line near it.  (I think the last time it
>     appeared when I did M-^ on the line following, but I could be wrong.  There
>     is nothing wrong with the code preceding the misfontification.) 
>
>     Editing the line or lines above it do not make the fontification
>     permanently go away.  For example, if I comment out all preceding lines,
>     the fontification is removed.  However, when I remove the comments, it
>     comes back.  The only way I've found to get rid of it is to turn
>     font-lock-mode off and on. 
>
>     It's driving me mad because I can't work out what, in terms of the code
>     preceding it, is causing it to fontify in this way.  In one case, the
>     function call was the first statement in the method, and I noticed that the
>     text also had the "c-in-sws" property (as well as the "face" property). 
>     Debugging through cc-engine.el doesn't look fun and I don't know if the
>     presence of this property is a red herring.
>
>     I can't reproduce it, so I'm really asking for help.  Any ideas?  What can
>     I do to work out what is going wrong?
>
>     Simon.
>
>
>
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the named recipient of this
> email please notify us immediately and do not copy it or use it for any
> purpose, nor disclose its contents to any other person.   
>
>  
>
> Misys Banking Systems is a trading name of Misys International Banking Systems
> Limited which is registered in England and Wales under company registration
> number 00971479 and with its registered office address at Burleigh House,
> Chapel Oak, Salford Priors, Evesham WR11 8SP.
>
>  
>
> THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU
> AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED
> CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE
> IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING.
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Tetris trademark

[Lennart Borgman (gmail)]

Chris Moore wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>>     Is anybody concerned that lisp/play/tetris.el might be a trademark
>>     infringement?
>>
>> File names and function names usually do not raise a trademark issue.
>> So there is no need to worry about this.
> 
> But what about the game itself?  It's not just the name of the file
> and functions, but the Tetris game itself is "subject to the
> registered copyrights of Tetris Holding LLC" (according to
> http://www.tetris.com/).


I think there are some useful notes about this on

   http://en.wikipedia.org/wiki/Tetris#History

See the end of the History section. It seems like you can not copyright 
a game, but I do not understand the details there.

Re: Tetris trademark

[Richard Stallman]

    But what about the game itself?  It's not just the name of the file
    and functions, but the Tetris game itself is "subject to the
    registered copyrights of Tetris Holding LLC" (according to
    http://www.tetris.com/).

My understanding is that game rules as such are not copyrightable.

    Incidentally, I just tried running M-x tetris RET.  After playing 2
    games, a buffer appeared called 'tetris-scores' showing 3 scores:

    03037   Sat Jan 27 13:48:27 2007       <x@SERVER>
    03031   Sat Jan 27 13:48:27 2007        <x@SERVER>
    00349   Sat Jan 27 13:34:52 2007         <x@SERVER>

Can you debug this?

Re: Tetris trademark

[Leo]

On 2007-01-26, Chip Coldwell said:

> Is anybody concerned that lisp/play/tetris.el might be a trademark
> infringement?
>
> Chip

Some distributions have removed tetris.el due to this concern.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Font-lock decides function call is function declaration in C+ +

[Chong Yidong]

Does this bug still exist with latest CVS?  If so, please provide a
simple test case (I couldn't find one in your previous messages).

> Hi, this bug remains[*] and a quick look at the C++ file I am editing shows
> that most of my methods have ended up with this sort of misfontification
> somewhere.  Note that misfontification does not occur during initial
> fontification, only after editing (though not in a way I can replicate).  I
> guess sometimes it thinks function calls are part of a declaration, though it
> doesn't necessarily happen when the preceding statement is a declaration.  In
> one occurrence in my C++ file, the misfontification has occurred immediately
> after a for loop.
>
> Again, I'm asking for help.  I never got a response last time.  What do I need
> to look at to see what is going on?
>
> [*] following my revision 1.18 date: 2006-11-15 16:31:03 fix in cc-fonts.el of
> another unrelated issue in CVS Emacs, Emacs CVS fontifies the below with
> font-lock-variable-name-face, rather than font-lock-function-name-face, which
> may/may not give a pointer to where the problem lies.
>
>     _____________________________________________
>     From:   Marshall, Simon 
>     Sent:   07 September 2006 17:41
>     To:     'bug-cc-mode@gnu.org'
>     Cc:     'emacs-pretest-bug@gnu.org'
>     Subject:        Font-lock decides function call is function declaration in
>     C++
>
>     Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of
>     code of the form:
>
>             foo(bar);
>
>     Or:
>
>             foo() = bar;
>
>     Are function declarations, and puts font-lock-function-name-face on (in
>     these examples) "foo".  It seems to happen when I am editing the line in
>     question, or maybe just on a line near it.  (I think the last time it
>     appeared when I did M-^ on the line following, but I could be wrong.  There
>     is nothing wrong with the code preceding the misfontification.) 
>
>     Editing the line or lines above it do not make the fontification
>     permanently go away.  For example, if I comment out all preceding lines,
>     the fontification is removed.  However, when I remove the comments, it
>     comes back.  The only way I've found to get rid of it is to turn
>     font-lock-mode off and on. 
>
>     It's driving me mad because I can't work out what, in terms of the code
>     preceding it, is causing it to fontify in this way.  In one case, the
>     function call was the first statement in the method, and I noticed that the
>     text also had the "c-in-sws" property (as well as the "face" property). 
>     Debugging through cc-engine.el doesn't look fun and I don't know if the
>     presence of this property is a red herring.
>
>     I can't reproduce it, so I'm really asking for help.  Any ideas?  What can
>     I do to work out what is going wrong?
>
>     Simon.
>
>
>
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the named recipient of this
> email please notify us immediately and do not copy it or use it for any
> purpose, nor disclose its contents to any other person.   
>
>  
>
> Misys Banking Systems is a trading name of Misys International Banking Systems
> Limited which is registered in England and Wales under company registration
> number 00971479 and with its registered office address at Burleigh House,
> Chapel Oak, Salford Priors, Evesham WR11 8SP.
>
>  
>
> THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU
> AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED
> CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE
> IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING.
>
> _______________________________________________
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

RE: Font-lock decides function call is function declaration in C+ +

[Marshall, Simon]

> Does this bug still exist with latest CVS?  If so, please provide a
> simple test case (I couldn't find one in your previous messages).

Yes, it does, with CVS Emacs as of 05/02/2007.  Originally, I couldn't
reproduce it on demand.  That's why, originally, I was asking for help to
track it down.

But, messing around just now, I've finally managed to do it.  I can't say
that these are the only way of reproducing it, as I've seen this
misfontification in a variety of situations that do not look obviously like
these.

1.  The goal is to write the code snippet:

int main() {
  foo();
  bar();
}

emacs -Q foo.cpp
int SPC main() SPC { RET } RET C-p C-o bar();

OK so far.  Now to insert the "foo();" line:

C-a C-o foo

At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
Now:

()

The fontification of "foo" and "bar" disappears.  OK.  Now complete the
snippet:

;

Now "foo" is fontified as a variable.  This is wrong.

2.  Here's a variation.  This time, the goal is to write the code snippet:

int main() {
  foo(fubar);
  bar();
}

emacs -Q bar.cpp
int SPC main() SPC { RET } RET C-p C-o bar();

OK so far.  Now to insert the "foo(fubar);" line:

C-a C-o foo(fubar

At this point, "bar" is fontified as a type.  Not sure why, but still.  Now:

);

Now "bar" is fontified as a variable.  This is wrong.

What is worse is that in both cases I cannot get rid of the misfontification
without turning Font Lock mode off and on again.

I hope this help to fix The Most Annoying Fontification Bug Ever.  Simon.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

Re: Font-lock decides function call is function declaration in C+ +

[Chong Yidong]

"Marshall, Simon" <simon.marshall@misys.com> writes:

> emacs -Q foo.cpp
> int SPC main() SPC { RET } RET C-p C-o bar();
>
> OK so far.  Now to insert the "foo();" line:
>
> C-a C-o foo
>
> At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
> Now:
>
> ()
>
> The fontification of "foo" and "bar" disappears.  OK.  Now complete the
> snippet:
>
> ;
>
> Now "foo" is fontified as a variable.  This is wrong.

I can reproduce this now.  Note that it only happens in c++ mode, not
in plain c-mode.

Hopefully, someone familiar with the cc-mode code can debug it.

Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie]

Hi, Simon!

On Mon, Feb 05, 2007 at 04:46:32PM -0000, Marshall, Simon wrote:
> > Does this bug still exist with latest CVS?  If so, please provide a
> > simple test case (I couldn't find one in your previous messages).

> Yes, it does, with CVS Emacs as of 05/02/2007.  Originally, I couldn't
> reproduce it on demand.  That's why, originally, I was asking for help to
> track it down.

> But, messing around just now, I've finally managed to do it.  I can't say
> that these are the only way of reproducing it, as I've seen this
> misfontification in a variety of situations that do not look obviously like
> these.

> 1.  The goal is to write the code snippet:

> int main() {
>   foo();
>   bar();
> }

> emacs -Q foo.cpp
> int SPC main() SPC { RET } RET C-p C-o bar();

> OK so far.  Now to insert the "foo();" line:

> C-a C-o foo

> At this point, "foo" is fontified as a type, and "bar" as a variable.  OK.
> Now:

> ()

> The fontification of "foo" and "bar" disappears.  OK.  Now complete the
> snippet:

> ;

> Now "foo" is fontified as a variable.  This is wrong.

It is indeed wrong.  

Further observations:
(i) The bug doesn't happen in C Mode.
The bug happens:
(ii) in Emacs 5.21.3/CC Mode 5.31.4
(iii) With jit-lock disabled (thankfully ;-)
(iv) in Emacs 5.21.3/CC Mode 5.30.3

So it seems its entirely a CC Mode bug.  I'm going to try and track it
down, though I suspect it could be quite tricky to find.  Thanks for
giving that recipe for producing the bug.

> 2.  Here's a variation.  [ snipped ]

> What is worse is that in both cases I cannot get rid of the
> misfontification without turning Font Lock mode off and on again.

M-o M-o fixes the fontification for me.

> I hope this help to fix The Most Annoying Fontification Bug Ever.
> Simon.

I think there're also other candidates for that description.  ;-(

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: Font-lock decides function call is function declaration in C+ +

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Further observations:
> (i) The bug doesn't happen in C Mode.
> The bug happens:
> (ii) in Emacs 5.21.3/CC Mode 5.31.4
> (iii) With jit-lock disabled (thankfully ;-)
> (iv) in Emacs 5.21.3/CC Mode 5.30.3
>
> So it seems its entirely a CC Mode bug.  I'm going to try and track it
> down, though I suspect it could be quite tricky to find.  Thanks for
> giving that recipe for producing the bug.

I think the problem is that when the buffer is in the state

  foo
  bar ();

foo looks like a type, so it is inserted in the cache variable
c-found-types.  When you add the "()":

  foo()
  bar();

this guess is no longer valid, but foo is not removed from
c-found-types.  Therefore, when you insert the final ";",

  foo();
  bar();

the call to foo(); is highlighted as though it were a constructor.
Note that if you do M-: (c-clear-found-types) prior to inserting the
final ";", the misfontification does not occur.

I don't know what the Right Fix is, however.

Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie]

Hi, Chong!

On Fri, Feb 09, 2007 at 04:25:21PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> I think the problem is that when the buffer is in the state

>   foo
>   bar ();

> foo looks like a type, so it is inserted in the cache variable
> c-found-types.

Exactly!  Thanks for that.

> When you add the "()":

>   foo()
>   bar();

> this guess is no longer valid, but foo is not removed from
> c-found-types.  Therefore, when you insert the final ";",

>   foo();
>   bar();

> the call to foo(); is highlighted as though it were a constructor.
> Note that if you do M-: (c-clear-found-types) prior to inserting the
> final ";", the misfontification does not occur.

> I don't know what the Right Fix is, however.

Once a variable has been inserted into c-found-types, it will stay there
almost for ever; it will stay there until re-fontification is done from
BOB (I'm not sure whether or not that also means (point-min) on a
narrowed buffer).  This permanence seems to be the fundamental problem.

To Simon: Sorry about my saying that "M-o M-o will clear the spurious
font-lock-type-face".  It only does that when point is within 16 lines of
BOB.  :-(

I think a solution might be to remove "foo" from c-found-types whenever
text is inserted/deleted in the vicinity of "foo\n bar ();" which
syntactically destroys its status as a type identifier.  I'll need to
think a lot more about this.

-- 
Alan.

Re: Font-lock decides function call is function declaration in C+ +

[Stefan Monnier]

> I think a solution might be to remove "foo" from c-found-types whenever
> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> syntactically destroys its status as a type identifier.  I'll need to
> think a lot more about this.

I'd be interested to know what solution you end up using.  I've bumped into
a similar problem in sml-mode where I tried to look at the infix precedence
declarations in the file while font-locking to adjust the indentation
algorithm.

The best solution I found so far is to add a special text property covering
the "infix" declaration and whose value is the symbol whose precedence and
associativity is being set, and then in font-lock-unfontify-region I begin
by looking for this special property and removing the corresponding symbols
from the precedence table.  But this failed when the whole line was deleted
since the unfontify gets called after the text (and its text-property) is
removed (i.e. too late), so I ended up using before-change-functions
instead, which seemed too costly compared to the importance of the feature,
so it's still in the "experimental" state.

Maybe a better approach is to use overlays rather than text-properties, so
they don't completely disappear if the text is removed.


        Stefan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Font-lock decides function call is function declaration in C+ +

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Once a variable has been inserted into c-found-types, it will stay there
> almost for ever; it will stay there until re-fontification is done from
> BOB (I'm not sure whether or not that also means (point-min) on a
> narrowed buffer).  This permanence seems to be the fundamental problem.
>
> I think a solution might be to remove "foo" from c-found-types whenever
> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> syntactically destroys its status as a type identifier.  I'll need to
> think a lot more about this.

For the Emacs 22 release, if no simple fix is forthcoming, could we
simply get font-lock to avoid higlighting constructor functions?

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Font-lock decides function call is function declaration in C+ +

[Stefan Monnier]

>> Once a variable has been inserted into c-found-types, it will stay there
>> almost for ever; it will stay there until re-fontification is done from
>> BOB (I'm not sure whether or not that also means (point-min) on a
>> narrowed buffer).  This permanence seems to be the fundamental problem.
>> 
>> I think a solution might be to remove "foo" from c-found-types whenever
>> text is inserted/deleted in the vicinity of "foo\n bar ();" which
>> syntactically destroys its status as a type identifier.  I'll need to
>> think a lot more about this.

> For the Emacs 22 release, if no simple fix is forthcoming, could we
> simply get font-lock to avoid higlighting constructor functions?

Or to not try to auto-learn types,


        Stefan

Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie]

Hi, Chong and Stefan!

On Sun, Feb 11, 2007 at 06:18:34PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Once a variable has been inserted into c-found-types, it will stay
> > there almost for ever; it will stay there until re-fontification is
> > done from BOB (I'm not sure whether or not that also means
> > (point-min) on a narrowed buffer).  This permanence seems to be the
> > fundamental problem.

> > I think a solution might be to remove "foo" from c-found-types
> > whenever text is inserted/deleted in the vicinity of "foo\n bar ();"
> > which syntactically destroys its status as a type identifier.  I'll
> > need to think a lot more about this.

> For the Emacs 22 release, if no simple fix is forthcoming, could we
> simply get font-lock to avoid higlighting constructor functions?

Give me a few more days, please!

int main () {
   foo(               <=================
   bar();
}

I think I can now see how to do this removal of "foo" from c-found-types:
After experimenting with C++ Mode, I conjecture that each "critical" use
of "foo" is marked with one of the values (c-decl-id-start
c-decl-type-start) for the property c-type.  (Hint: it's not at the
buffer position you might expect.)

If this proves true, or almost true, it will be easy enough to amend CC
Mode's before/after-change function to remove these identifiers from
c-found-types.

Give me a few more days to try this out, please!

-- 
Alan Mackenzie (Ittersbach, Germany).

RE: Font-lock decides function call is function declaration in C+ +

[Marshall, Simon]

> So it seems its entirely a CC Mode bug.  I'm going to try and 
> track it down, though I suspect it could be quite tricky to 
> find.  Thanks for giving that recipe for producing the bug.

Thanks.

> > I hope this help to fix The Most Annoying Fontification Bug Ever.
> 
> I think there're also other candidates for that description.  ;-(

Don't poke the monster.

Uh-huh, he's woken.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

RE: Font-lock decides function call is function declaration in C+ +

[Marshall, Simon]

> >> Once a variable has been inserted into c-found-types, it will stay
there
> >> almost for ever; it will stay there until re-fontification is done from
> >> BOB (I'm not sure whether or not that also means (point-min) on a
> >> narrowed buffer).  This permanence seems to be the fundamental problem.
> >> 
> >> I think a solution might be to remove "foo" from c-found-types whenever
> >> text is inserted/deleted in the vicinity of "foo\n bar ();" which
> >> syntactically destroys its status as a type identifier.  I'll need to
> >> think a lot more about this.
> 
> > For the Emacs 22 release, if no simple fix is forthcoming, could we
> > simply get font-lock to avoid higlighting constructor functions?
> 
> Or to not try to auto-learn types,

Yes, unfortunately, I think that if you try to learn types on-the-fly then
you will always be vulnerable to this sort of problem.  The issue is that
cc-mode needs to know as soon as a change invalidates it as a candidate type
(ie, deletion of some/all of the text "foo" or interruption of the
whitespace between "foo" and its candidate identifier "bar").  I can think
of a few ways you could attempt to do it, but they are a bit intensive and
far from simple.

Perhaps cc-mode should only try to learn types when fontifying the whole
buffer?

Simon.


This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person.       Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. 

RE: Font-lock decides function call is function declaration in C+ +

[Stuart D. Herring]

> Yes, unfortunately, I think that if you try to learn types on-the-fly then
> you will always be vulnerable to this sort of problem.  The issue is that
> cc-mode needs to know as soon as a change invalidates it as a candidate
> type
> (ie, deletion of some/all of the text "foo" or interruption of the
> whitespace between "foo" and its candidate identifier "bar").  I can think
> of a few ways you could attempt to do it, but they are a bit intensive and
> far from simple.

It's worse than that.  Inserting a new letter that changes "foo", or
transposing two characters 3k back in the buffer that cause the whole
region to become a comment, or deleting "bar", or exchanging "foo" and
"bar", or merely exchanging 'f' and 'o', or adding #define in front of
"foo", or... any of which could be done as one change by an appropriate
Lisp helper function.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Font-lock decides function call is function declaration in C+ +

[Stefan Monnier]

>> Yes, unfortunately, I think that if you try to learn types on-the-fly then
>> you will always be vulnerable to this sort of problem.  The issue is that
>> cc-mode needs to know as soon as a change invalidates it as a candidate
>> type
>> (ie, deletion of some/all of the text "foo" or interruption of the
>> whitespace between "foo" and its candidate identifier "bar").  I can think
>> of a few ways you could attempt to do it, but they are a bit intensive and
>> far from simple.

> It's worse than that.  Inserting a new letter that changes "foo", or
> transposing two characters 3k back in the buffer that cause the whole
> region to become a comment, or deleting "bar", or exchanging "foo" and
> "bar", or merely exchanging 'f' and 'o', or adding #define in front of
> "foo", or... any of which could be done as one change by an appropriate
> Lisp helper function.

Yes, of course, the case of commenting code needs to be handled as well, but
re-using the font-lock machinery makes it "somewhat painless".


        Stefan

Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie]

Evening, Stuart and Simon!

On Mon, Feb 12, 2007 at 07:53:53AM -0800, Stuart D. Herring wrote:
> > Yes, unfortunately, I think that if you try to learn types
> > on-the-fly then you will always be vulnerable to this sort of
> > problem.  The issue is that cc-mode needs to know as soon as a
> > change invalidates it as a candidate type (ie, deletion of some/all
> > of the text "foo" or interruption of the whitespace between "foo"
> > and its candidate identifier "bar").  I can think of a few ways you
> > could attempt to do it, but they are a bit intensive and far from
> > simple.

This is true, but such a way has already been built into CC Mode (by
Martin Stjernholm).  It just[*] needs a little tweaking.

[*] To the cynical - hold off a few days before commenting on this
adverb, please!

> It's worse than that.  Inserting a new letter that changes "foo", ...

is taken care of, in the commonest case.  When you type the "l" after
"foo", this replaces "foo" with "fool" in the cache c-found-types.

> ... or transposing two characters 3k back in the buffer that cause the
> whole region to become a comment, ....

is a problem throughout lots of modes in Emacs.  c-found-types doesn't
exacerbate it much (or at all?) for CC Mode.

> ... or deleting "bar", or exchanging "foo" and "bar", or merely
> exchanging 'f' and 'o', or adding #define in front of "foo", or... any
> of which could be done as one change by an appropriate Lisp helper
> function.

I think most of these can be made to work quite soon, if they don't
already.  However, you're more than welcome to test these scenarios out
and post the results here.  ;-)

> Davis

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: Font-lock decides function call is function declaration in C+ +

[Stuart D. Herring]

>> It's worse than that.  Inserting a new letter that changes "foo", ...
>
> is taken care of, in the commonest case.  When you type the "l" after
> "foo", this replaces "foo" with "fool" in the cache c-found-types.

Perhaps the cache should note how many times something is used?  Then the
relatively common case of

socket s;
socket_factory sf/*=...*/;
s.initializeFrom(sf);

would not remove `socket' from the cache, but typo-corrections can still
change it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Font-lock decides function call is function declaration in C+ +

[Alan Mackenzie]

Hi, Stuart!

On Mon, Feb 12, 2007 at 10:06:22AM -0800, Stuart D. Herring wrote:
> >> It's worse than that.  Inserting a new letter that changes "foo", ...

> > is taken care of, in the commonest case.  When you type the "l" after
> > "foo", this replaces "foo" with "fool" in the cache c-found-types.

> Perhaps the cache should note how many times something is used?  Then the
> relatively common case of

> socket s;
> socket_factory sf/*=...*/;
> s.initializeFrom(sf);

> would not remove `socket' from the cache, but typo-corrections can still
> change it.

NO!!!  It isn't that sort of cache.  It's purely there to speed things
up, since without it, the various after-change functions would have to
analyse the source extensively for types for every character you type.

It's important that the cache contains most of the type identifiers.  It
doesn't much matter if one or two are missing.  What DOES matter is when
the cache has identifiers which aren't types (even if they once were).
This is what's causing the bug here.

I've got a clearer idea of where and how to remove ex-types than I did
last night.

> Davis

-- 
Alan.