ruby-mode

ruby-mode

[Seiji Zenitani]

Hi,

I hear that the emacs trunk is now open to new features.  I think  
it's time to include ruby-mode to the emacs main distribution,  
considering the recent popularity of the ruby language.  The ruby  
developers agreed with this idea when I asked them in 2005.  Are you  
OK to include ruby-mode for 22.2 or 23.0?  How to start?

Seiji Zenitani
zenitani@gmail.com

Re: ruby-mode

[David Kastrup]

Seiji Zenitani <zenitani@gmail.com> writes:

> I hear that the emacs trunk is now open to new features.

I don't think that this is an accurate characterization of the
situation.  There are several branches slated for merging, but the
details are not clear yet.  Some assessment is underway, however.
Much of it is tentative: no hard decisions have been reached yet.

> I think it's time to include ruby-mode to the emacs main
> distribution, considering the recent popularity of the ruby
> language.  The ruby developers agreed with this idea when I asked
> them in 2005.  Are you OK to include ruby-mode for 22.2 or 23.0?

It is not even clear whether 22.2+ will be just bugfixes or features.
Personally, I would lean towards making 22.* from the EMACS_22_BASE
branch and not put new package versions into it.  A new (rather
instead of an updated) mode might be borderline since there is no
merge work involved.

> How to start?

Making clear that copyright assignments for the whole code are
feasible and getting them underway.  But at the current point of time,
I don't think that the trunk has been declared open for new additions.
It is more like it is basically oked for non-trivial changes.  I don't
think it would be prudent to do package updates (or new package
additions), however, before we have merged the branches that are
feasible for merging.  Unicode-2 appears pretty much so, and it is
quite desirable to merge this before updates/additions since it
touches a lot across the board.

I am currently playing with the multi-tty branch and coming across
quite a few issues.  My vague first impression is that even if it may
be possible to make it compile under all platforms (not there yet), it
seems not ready for seamless work even on basically supported
platforms (here, GNOME + gtk+ 2.10): the list of issues in the
multitty README is not small, and I have encountered inconsistencies
and not-working material myself.

So my personal guess would be that unicode-2 would be the first to get
merged into trunk, and rather soon.  Once this stabilizes, it may make
more sense thinking about updating packages and adding new ones.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ruby-mode

[Thien-Thi Nguyen]

() David Kastrup <dak@gnu.org>
() Sun, 13 May 2007 20:05:05 +0200

   > I hear that the emacs trunk is now open to new features.

   I don't think that this is an accurate characterization of the
   situation.  There are several branches slated for merging, but the
   details are not clear yet.  Some assessment is underway, however.
   Much of it is tentative: no hard decisions have been reached yet.

   [...] at the current point of time, I don't think that the trunk has
   been declared open for new additions.

that's not the impression i got (from rms' post).

   [...] So my personal guess would be that unicode-2 would be the first
   to get merged into trunk, and rather soon.  Once this stabilizes, it
   may make more sense thinking about updating packages and adding new
   ones.

i think "open to new features" is perfectly accurate.  if the code for
ruby mode is like that for most normal language-specific modes, i cannot
imagine any dependencies it would have w/ multy-tty or unicode-2.
furthermore, those initiatives require pervasive changes, whereas the
addition of a single (say) progmodes/ruby-mode.el is No Big Deal.

ruby mode authors should feel free to post latest code to the mailing
list gnu-emacs-sources@gnu.org.  usually the maintainer (rms in the past
but perhaps someone else going forward (i don't know)) will ask the
poster if they would like to contribute the code to emacs, and if/when
agreed-upon, set in motion the legal side of the process.

thi

Re: ruby-mode

[Stefan Monnier]

> I hear that the emacs trunk is now open to new features.

Indeed.

> I think  it's time to include ruby-mode to the Emacs main distribution,
> considering the recent popularity of the ruby language.  The ruby
> developers agreed with this idea when I asked them in 2005.

> Are you OK to include ruby-mode for 22.2 or 23.0?  How to start?

It's up to Richardto decide, I guess, but I expect there'd be no problem
accepting ruby-mode on the trunk (which will turn into Emacs-23 at some
point in the future), as long as the legal paperwork is done.  I.e. the main
author(s) need to transfer their copyright to the FSF and the people who
submitted non-trivial patches need to sign a copyright-disclaimer.

I doubt it'll be included in Emacs-22.2 (I expect this release to be
bugfix-only), but maybe Emacs-22.3 will be open to a few minor feature
additions such as new packages.


        Stefan

Re: ruby-mode

[Seiji Zenitani]

On 2007/05/13, at 14:54, Thien-Thi Nguyen wrote:
>
> ruby mode authors should feel free to post latest code to the mailing
> list gnu-emacs-sources@gnu.org.  usually the maintainer (rms in the  
> past
> but perhaps someone else going forward (i don't know)) will ask the
> poster if they would like to contribute the code to emacs, and if/when
> agreed-upon, set in motion the legal side of the process.
>
> thi

I am contacting the ruby developers.

Seiji

adding new modes [was: Re: ruby-mode]

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > I hear that the emacs trunk is now open to new features.
  > 
  > Indeed.
  > 
  > > I think  it's time to include ruby-mode to the Emacs main distribution,
  > > considering the recent popularity of the ruby language.  The ruby
  > > developers agreed with this idea when I asked them in 2005.
  > 
  > > Are you OK to include ruby-mode for 22.2 or 23.0?  How to start?
  > 
  > It's up to Richardto decide, I guess, but I expect there'd be no problem
  > accepting ruby-mode on the trunk (which will turn into Emacs-23 at some
  > point in the future), as long as the legal paperwork is done.  I.e. the main
  > author(s) need to transfer their copyright to the FSF and the people who
  > submitted non-trivial patches need to sign a copyright-disclaimer.

What is the standard procedure for adding new modes to emacs (if
there's any)? I would be nice to see at least add verilog-mode and
vera-mode.

There was talk at some point about adding php-mode.

Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el

Re: adding new modes

[Stefan Monnier]

> What is the standard procedure for adding new modes to emacs (if
> there's any)? I would be nice to see at least add verilog-mode and
> vera-mode.

Basically, suggest it here, arguing why it's necessary.  Also the authors
should be willing to sign the relevant legal paperwork.

> There was talk at some point about adding php-mode.
> Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el

It all sounds OK to me, except for vc-p4 since p4 is non-free.


        Stefan

Re: adding new modes

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What is the standard procedure for adding new modes to emacs (if
>> there's any)? I would be nice to see at least add verilog-mode and
>> vera-mode.
>
> Basically, suggest it here, arguing why it's necessary.  Also the authors
> should be willing to sign the relevant legal paperwork.
>
>> There was talk at some point about adding php-mode.
>> Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el
>
> It all sounds OK to me, except for vc-p4 since p4 is non-free.

vc-git is not of release-quality (C-u C-x v = usually chokes while
trying to propose a "previous version").  However, the Emacs 23
release is not exactly around the door, and having it synched into
Emacs-CVS might be nice.  At the current point of time, it is
maintained in git's git repository.  Not all people with write access
there will have a copyright assignment.  So one would have to check
who actually wrote stuff in it.

We seem to have Xavier Maillard, David Kågedal, Jakub Narebski,
Alexandre Julliard, Sam Vilain, Karl Hasselström, Ville Skyttä, Tom
Prince (trivial change).  So that is not exactly an entirely small
list.  I can ask on the git list if people think this a good idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: adding new modes [was: Re: ruby-mode]

[Dan Nicolaescu]

  > What is the standard procedure for adding new modes to emacs (if
  > there's any)? I would be nice to see at least add verilog-mode and
  > vera-mode.
  > 
  > There was talk at some point about adding php-mode.
  > 
  > Also some more vc back-ends would be good: vc-hg, vc-git, 

vc-bzr.el would also be nice to have.

Re: adding new modes [was: Re: ruby-mode]

[Richard Stallman]

    Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el

Are these version control systems free?
If so we would like to support them.
We do not want to support non-free systems
(except SCCS, which is ok since it is obsolete and
we have a free emulator for it).

Re: adding new modes [was: Re: ruby-mode]

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el
  > 
  > Are these version control systems free?
  > If so we would like to support them.
  > We do not want to support non-free systems
  > (except SCCS, which is ok since it is obsolete and
  > we have a free emulator for it).

hg (aka mercurial), git and bzr are all free software.

Re: adding new modes

[Stefan Monnier]

>> Also some more vc back-ends would be good: vc-hg, vc-git, 
> vc-bzr.el would also be nice to have.

This one is already in the unicode branch (tho it's only been committed and
not really integrated cleanly yet).


        Stefan

Re: adding new modes

[Alexandre Julliard]

David Kastrup <dak@gnu.org> writes:

> vc-git is not of release-quality (C-u C-x v = usually chokes while
> trying to propose a "previous version").  However, the Emacs 23
> release is not exactly around the door, and having it synched into
> Emacs-CVS might be nice.  At the current point of time, it is
> maintained in git's git repository.  Not all people with write access
> there will have a copyright assignment.  So one would have to check
> who actually wrote stuff in it.

I'm the main author of vc-git.el and git.el, and I'd be happy to sign
the needed paperwork if you want to use them. I think most of the
changes done by other people would be in the tiny change category, or
I can rewrite them if needed.

It's true that vc-git is not very good at the moment, it's a quick
hack I put together because people were requesting it but I don't
really use it myself, so I'd be happy for someone to take over
maintenance. git.el is in better shape, and much more useful IMHO.

-- 
Alexandre Julliard
julliard@winehq.org

Re: adding new modes

[David Kastrup]

Alexandre Julliard <julliard@winehq.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> vc-git is not of release-quality (C-u C-x v = usually chokes while
>> trying to propose a "previous version").  However, the Emacs 23
>> release is not exactly around the door, and having it synched into
>> Emacs-CVS might be nice.  At the current point of time, it is
>> maintained in git's git repository.  Not all people with write access
>> there will have a copyright assignment.  So one would have to check
>> who actually wrote stuff in it.
>
> I'm the main author of vc-git.el and git.el, and I'd be happy to sign
> the needed paperwork if you want to use them. I think most of the
> changes done by other people would be in the tiny change category, or
> I can rewrite them if needed.
>
> It's true that vc-git is not very good at the moment, it's a quick
> hack I put together because people were requesting it but I don't
> really use it myself, so I'd be happy for someone to take over
> maintenance. git.el is in better shape, and much more useful IMHO.

There is also git-blame which currently feels like it has an
interactivity issue: it should probably not parse everything it gets
at once, but rather in smaller chunks via an idle-hook.

I'll send you the assignment request in a separate mail.  Personally,
I think that Emacs should support git out of the box: git is actually
the most "bazaaresque" system I know: one does not need to put
identification into files, and one can even split large files up and
stuff and move and rename them without telling the version control
system, and it will still manage to reasonably track stuff.  And one
does not need access to non-local repositories, and it is quite
convenient for developing on local shadow branches of Subversion/CVS
checkouts without needing upstream support.

Some of its concepts might not fit perfectly within the VC framework
(like the index file and parts of its branching and patchset model):
for that reason alone, it would be good to continue development of the
git Elisp packages in the Emacs tree itself: that way, vc can be
adapted if necessary.

I'll leave it to you to contact other developers, ask them to consider
the assignment, and send them the request forms: if you need
additional explanations about why they are required and what they
imply, feel free to contact me, or the copyright clerk.

And thanks!

-- 
David Kastrup

Re: adding new modes

[Richard Stallman]

    > There was talk at some point about adding php-mode.
    > Also some more vc back-ends would be good: vc-hg, vc-git, and maybe vc-p4.el

    It all sounds OK to me, except for vc-p4 since p4 is non-free.

The reason we refuse to support non-free version control systems is to
give support the use of the free ones.  This is part of a more general
policy where we don't support use of Emacs with non-free software
unless it is very widely used (like Windows or MacOS).

Re: adding new modes

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> What is the standard procedure for adding new modes to emacs (if
> there's any)? I would be nice to see at least add verilog-mode and
> vera-mode.
...

I think it would be good if Emacs included "lua-mode.el":

   http://luaforge.net/projects/lua-mode/

Lua is a very nice scripting/embedded language[*].

Both mode and language are free software (lua-mode.el is GPLed, Lua
itself uses the MIT license).

-miles

[*] http://en.wikipedia.org/wiki/Lua_programming_language

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: adding new modes

[Juanma Barranquero]

On 5/28/07, Miles Bader <miles.bader@necel.com> wrote:

> I think it would be good if Emacs included "lua-mode.el"

Sometime ago there was a request to include a ruby mode; though, truth
be told, the standard ruby distribution already includes such a mode:

  http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/misc/

             Juanma

Re: adding new modes

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 5/28/07, Miles Bader <miles.bader@necel.com> wrote:
>
>> I think it would be good if Emacs included "lua-mode.el"
>
> Sometime ago there was a request to include a ruby mode; though, truth
> be told, the standard ruby distribution already includes such a mode:
>
>  http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/misc/

Well, "include" and "create" are two different things, so it is not
surprising that a mode already exists.

What we need to evaluate in such cases is whether

a) the mode works with Emacs 22+ sufficiently well
b) has the functionality one would expect from some a standard mode
c) has a current pace of change that does not make its inclusion into
Emacs (which optimistically speaking won't get release updates more
than twice a year) absurd
d) is a language of sufficient interest for free software

The last point is, in my opinion, the case for both Lua and Ruby.  I
have no data or experience to judge the other points.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: adding new modes

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> I think it would be good if Emacs included "lua-mode.el"
>
> Sometime ago there was a request to include a ruby mode; though, truth
> be told, the standard ruby distribution already includes such a mode:

I don't know if lua-mode.el is a standard part of the lua distribution,
but there are signs that it is not (e.g. the fact that it's a separate
project on "luaforge").  [It's not part of the standard debian lua
install, though debian often splits things up more than usual.]

In any case, I don't think it matters very much:  lua is very common as
an extension/embedded language, so there are many programs for which one
might want to write some lua code, without having lua "installed" per se
(lua is so small that it's often linked statically, so you don't even
necessarily have lua libraries around)!

I think it would be great if Emacs would "just work" for such cases.

Indeed, even with more heavyweight languages where it's more common for
users to explicitly install the langage, I think there are enough issues
with separately distributed modes that it's nice to also include them
with Emacs when practical (the ruby developers seem to agree since they
requested the inclusion...).

-miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: adding new modes

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> What we need to evaluate in such cases is whether
>
> a) the mode works with Emacs 22+ sufficiently well
> b) has the functionality one would expect from some a standard mode
> c) has a current pace of change that does not make its inclusion into
> Emacs (which optimistically speaking won't get release updates more
> than twice a year) absurd
> d) is a language of sufficient interest for free software
>
> The last point is, in my opinion, the case for both Lua and Ruby.  I
> have no data or experience to judge the other points.

I'd say, for lua-mode.el:

a) I'm currently using lua-mode.el as distributed by debian, and haven't
   noticed any obvious problems (there are some compilation warnings
   which should probably be fixed up)

b) It does proper indentation and syntax highlighting, so I'd say yes

c) Doesn't seem too bad in this respect:  the last two releases were
   2006-12-08 and 2006-06-25, and it works pretty well already

d) Yes, definitely; it's used as an extension language by many projects

I can't say anything for ruby-mode with respect to (a)-(c), but I agree
about (d) -- ruby is certainly very popular, and is free software

-miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: adding new modes

[Richard Stallman]

    I think it would be good if Emacs included "lua-mode.el":

       http://luaforge.net/projects/lua-mode/

Have you checked that it is well written and fits into Emacs well
as a major mode?  That it doesn't do anything bizarre which major
modes should not do?

If so, could you ask the author(s) of lua-mode.el to contact me?


We could include a mode for Ruby on the same two conditions.


    Lua
    itself uses the MIT license).

MIT uses many licenses, so it is best to call this the X11 license.

new VC backend: vc-git added, please test (was: Re: adding new modes)

[Dan Nicolaescu]

Alexandre Julliard <julliard@winehq.org> writes:

  > David Kastrup <dak@gnu.org> writes:
  > 
  > > vc-git is not of release-quality (C-u C-x v = usually chokes while
  > > trying to propose a "previous version").  However, the Emacs 23
  > > release is not exactly around the door, and having it synched into
  > > Emacs-CVS might be nice.  At the current point of time, it is
  > > maintained in git's git repository.  Not all people with write access
  > > there will have a copyright assignment.  So one would have to check
  > > who actually wrote stuff in it.
  > 
  > I'm the main author of vc-git.el and git.el, and I'd be happy to sign
  > the needed paperwork if you want to use them. 

Thank you for doing this!

vc-git.el is now checked in CVS HEAD.

It is not enabled by default, it would be nice if people could test it
a bit more before doing that. 

There are still VC functions that need to be implemented. See the Todo
section and the beginning of the file.

Quite a few of or the missing functions should be very easy: knowing
what git command should be run should probably be enough.

Re: new VC backend: vc-git added, please test

[David Kastrup]

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

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Alexandre Julliard <julliard@winehq.org> writes:
>
>   > David Kastrup <dak@gnu.org> writes:
>   > 
>   > > vc-git is not of release-quality (C-u C-x v = usually chokes while
>   > > trying to propose a "previous version").  However, the Emacs 23
>   > > release is not exactly around the door, and having it synched into
>   > > Emacs-CVS might be nice.  At the current point of time, it is
>   > > maintained in git's git repository.  Not all people with write access
>   > > there will have a copyright assignment.  So one would have to check
>   > > who actually wrote stuff in it.
>   > 
>   > I'm the main author of vc-git.el and git.el, and I'd be happy to sign
>   > the needed paperwork if you want to use them. 
>
> Thank you for doing this!
>
> vc-git.el is now checked in CVS HEAD.
>
> It is not enabled by default, it would be nice if people could test it
> a bit more before doing that. 
>
> There are still VC functions that need to be implemented. See the Todo
> section and the beginning of the file.
>
> Quite a few of or the missing functions should be very easy: knowing
> what git command should be run should probably be enough.

Well, I had a working version of annotation before esr did the code
changes in CVS.  I include it for reference in case somebody wants to
look at what might be missing to make it run again.  Short of time,
and getting annoyed by other bugs and incompatibilities, I have pinned
my VC to a version before the change for now.


[-- Attachment #2: vc-git.el --]
[-- Type: application/emacs-lisp, Size: 8248 bytes --]

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: new VC backend: vc-git added, please test

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Well, I had a working version of annotation before esr did the code
  > changes in CVS.  I include it for reference in case somebody wants to
  > look at what might be missing to make it run again.  Short of time,
  > and getting annoyed by other bugs and incompatibilities, I have pinned
  > my VC to a version before the change for now.

Annotate works fine for me with CVS HEAD... 

Re: new VC backend: vc-git added, please test

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Well, I had a working version of annotation before esr did the code
>   > changes in CVS.  I include it for reference in case somebody wants to
>   > look at what might be missing to make it run again.  Short of time,
>   > and getting annoyed by other bugs and incompatibilities, I have pinned
>   > my VC to a version before the change for now.
>
> Annotate works fine for me with CVS HEAD... 

You mean, you can go backwards and forwards in time and move to the
version previously in a line?  N P and A all work?

I have not had the time to check what version exactly was checked in.
It is obvious that some work has been done on it, or it would not have
worked with the new VC framework.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: new VC backend: vc-git added, please test

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Well, I had a working version of annotation before esr did the code
  > >   > changes in CVS.  I include it for reference in case somebody wants to
  > >   > look at what might be missing to make it run again.  Short of time,
  > >   > and getting annoyed by other bugs and incompatibilities, I have pinned
  > >   > my VC to a version before the change for now.
  > >
  > > Annotate works fine for me with CVS HEAD... 
  > 
  > You mean, you can go backwards and forwards in time and move to the
  > version previously in a line?  N P and A all work?

Sure.

  > I have not had the time to check what version exactly was checked in.
  > It is obvious that some work has been done on it, or it would not have
  > worked with the new VC framework.

Obviously. The changes for the new VC framework were under 10 lines of
code. 

Re: adding new modes

[Glenn Morris]

Richard Stallman wrote:

>     I think it would be good if Emacs included "lua-mode.el":
>
>        http://luaforge.net/projects/lua-mode/
>
> Have you checked that it is well written and fits into Emacs well
> as a major mode?  That it doesn't do anything bizarre which major
> modes should not do?
>
> If so, could you ask the author(s) of lua-mode.el to contact me?


Hi,

Did anything happen about this (installing lua-mode.el)?


I took a quick look at lua-mode.el. It has had quite a few authors
over the years, some just listed as "various", so getting assignments
might be difficult. Oddly, it describes itself as "Copyright FSF", yet
I cannot see any of the main authors in copyright.list...

lua-mode

[Richard Stallman]

Nothing has happened.  Would you like to contact the authors and see
if they wish to assign?

Re: lua-mode

[Glenn Morris]

Richard Stallman wrote:

> Nothing has happened.  Would you like to contact the authors and see
> if they wish to assign?

I sent the current maintainer a mail.

Re: lua-mode

[Juergen Hoetzel]

On Sun, Oct 07, 2007 at 02:56:20AM -0400, Glenn Morris wrote:
> Richard Stallman wrote:
> 
> > Nothing has happened.  Would you like to contact the authors and see
> > if they wish to assign?
> 
> I sent the current maintainer a mail.
> 

I took maintainer-ship for Lua-mode in May 2006. I only wrote part of
the code.

There are some issues with the current codebase. The indention code is
quite a hack.

So i decided to not work on current codebase anymore. Instead I'm
doing a complete clean rewrite for GNU Emacs 22 at the moment. By the
way this will solve the copyright issue. I will keep you informed on
this list.

Jürgen

Re: lua-mode

[Richard Stallman]

    So i decided to not work on current codebase anymore. Instead I'm
    doing a complete clean rewrite for GNU Emacs 22 at the moment. By the
    way this will solve the copyright issue. I will keep you informed on
    this list.

Thank you.

lua-mode

[Miles Bader]

Anyone know what happened to lua-mode?

Last I knew, one of the authors wanted to rewrite it (for code
cleanliness and ease of copyright assignment), but I haven't heard
anything for a long while.

I sent mail to him last January, but never got a reply.

Has anyone been in contact with him?

Thanks,

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: lua-mode

[Jürgen Hötzel]

On Fri, Jul 25, 2008 at 12:11:19PM +0900, Miles Bader wrote:
> Anyone know what happened to lua-mode?

Sorry: the rewrite is still on my TODO-list! But i had no time
yet. Any contribution would be appreciated!

Jürgen

Re: lua-mode

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 25, 2008 at 07:51:00AM +0200, Jürgen Hötzel wrote:
> On Fri, Jul 25, 2008 at 12:11:19PM +0900, Miles Bader wrote:
> > Anyone know what happened to lua-mode?
> 
> Sorry: the rewrite is still on my TODO-list! But i had no time
> yet. Any contribution would be appreciated!

Is there any publically accessible code to contribute to? I can't
make any promises at the moment, but I would be quite interested
to have a lua mode working.

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIkvwiBcgs9XrR2kYRAmE8AJ9dqxisNSa2LRz0Z4A1NZ74/55N2gCfUKlO
CIbt/h4VzFDGpfRQ/aNQySY=
=gmmN
-----END PGP SIGNATURE-----