March 06, 2007
Charlie wrote:
>  > When Emacs 22 is
>  > officially release with its cc-mode 5.3x, massive numbers of niche,
>  > minimally-supported modes are going to break.
> 
> Yea , which apparently is right around the corner.  I've got a few modes that are probably going to break.
> 
> I'll let the php-mode guys know.
> 
> I hope nxml doesn't rely on cc-mode, then I'll be stuck with 21.

I would highly doubt that it does.  cc-mode is really only useful as a base for languages that look more or less like C.  Curly brace languages in other words.  For instance python-mode and the ML mode I've seen are not based on cc-mode because the differences in the languages are too great.  I'm sure the difference between C and XML is also too great.

--bb
March 28, 2007
Bill Baxter wrote:
> Charlie wrote:
>>  > When Emacs 22 is
>>  > officially release with its cc-mode 5.3x, massive numbers of niche,
>>  > minimally-supported modes are going to break.
>>
>> Yea , which apparently is right around the corner.  I've got a few modes that are probably going to break.
>>
>> I'll let the php-mode guys know.
>>
>> I hope nxml doesn't rely on cc-mode, then I'll be stuck with 21.
> 
> I would highly doubt that it does.  cc-mode is really only useful as a base for languages that look more or less like C.  Curly brace languages in other words.  For instance python-mode and the ML mode I've seen are not based on cc-mode because the differences in the languages are too great.  I'm sure the difference between C and XML is also too great.

Suggestion for d-mode.el: add unittest to the list of keywords starting on line 218.

Andrei
March 29, 2007
Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Charlie wrote:
>>>  > When Emacs 22 is
>>>  > officially release with its cc-mode 5.3x, massive numbers of niche,
>>>  > minimally-supported modes are going to break.
>>>
>>> Yea , which apparently is right around the corner.  I've got a few modes that are probably going to break.
>>>
>>> I'll let the php-mode guys know.
>>>
>>> I hope nxml doesn't rely on cc-mode, then I'll be stuck with 21.
>>
>> I would highly doubt that it does.  cc-mode is really only useful as a base for languages that look more or less like C.  Curly brace languages in other words.  For instance python-mode and the ML mode I've seen are not based on cc-mode because the differences in the languages are too great.  I'm sure the difference between C and XML is also too great.
> 
> Suggestion for d-mode.el: add unittest to the list of keywords starting on line 218.
> 
> Andrei

Actually I think it should go at line 214 with the other "followed-directly-by-a-block" keywords. (a.k.a. "c-block-stmt-1-kwds").

I changed the wiki (which is actually the authoritative version).

--bb
May 29, 2007
Bill Baxter wrote:
> I changed the wiki (which is actually the authoritative version).

Hi, I patched some strange indentation of class constructor brackets when they are on their own line :

I like to type
>class Foo
>{
>  this ()
>  {
>    ...
>  }
>
>  void bar ()
>  {
>    ...
>  }
>}

But the wiki's d-mode would give me this
>class Foo
>{
>  this ()
>    {
>      ...
>    }
>
>  void bar ()
>  {
>    ...
>  }
>}

Modifying d-mode.el by adding "this" to *c-modifier-kwds* at line 146 fixed it, and even if it does not exactly match the comment, it does not seem to break anything else. I am no D expert yet but I figured I would let you know, and I'm too shy to modify the wiki without prior asking  =)

--
 Thomas de Grivel


June 04, 2007
Thomas de Grivel wrote:
> Bill Baxter wrote:
>> I changed the wiki (which is actually the authoritative version).
> 
> Hi, I patched some strange indentation of class constructor brackets
> when they are on their own line :
> 
> I like to type
>> class Foo
>> {
>>  this ()
>>  {
>>    ...
>>  }
>>
>>  void bar ()
>>  {
>>    ...
>>  }
>> }
> 
> But the wiki's d-mode would give me this
>> class Foo
>> {
>>  this ()
>>    {
>>      ...
>>    }
>>
>>  void bar ()
>>  {
>>    ...
>>  }
>> }
> 
> Modifying d-mode.el by adding "this" to *c-modifier-kwds* at line 146
> fixed it, and even if it does not exactly match the comment, it does not
> seem to break anything else. I am no D expert yet but I figured I would
> let you know, and I'm too shy to modify the wiki without prior asking  =)

Hmm, well I'd be more interested in the fix if

A) I actually saw the problem in my setup (your code indents fine for me)

and

B) If you could explain why the fix (pretending it's a c-modifier-kwd) works (which would also help clarify if it will have any unwanted side effects).

--bb
1 2
Next ›   Last »