More bugs in Custom themes

More bugs in Custom themes

[Luc Teirlinck]

As I already said in another message, things are still a _lot_ worse
than I thought yesterday.  The Custom themes feature in its current
form is actually completely unusable and it seems impossible to make
it usable without a substantial effort in correcting porting errors
and finishing off the porting work (and then documenting it).  As I
already pointed out, I am not the right person for this.

First new bug.  After requiring a theme and then setting and saving
some option through Custom, all my customizations for all options for
which the theme specified a value were deleted.  I lost part of my
Custom file this way and had to recreate it.  This is a serious bug.
It probably can be fixed one way or the other, but the three unfixed
bugs I am currently aware of are guaranteed to be only three of very
many.  Every time I try out something new, I find new bugs.  The
current Custom themes stuff is completely dysfunctional.  The current
code in custom.el appears to be incoherent.

Second new bug: `custom-create-theme' can not handle variables with
a defcustom that needs a :require and there are a lot of those.

At present, people should not be using Custom themes, because you risk
loosing part of your customizations by doing that.  This stuff should
definitely not be documented in the Emacs manual at present.

I guess it still makes sense to apply my patches.  In case somebody
sooner or later manages to fix the mess in custom.el, they still fix a
few of the many bugs, thereby making that person's job at least
somewhat easier.

I definitely no longer want to make `require-theme' interactive,
because using it, at present, can lead to loss of part of your Custom
file.  Until things get fixed (if ever), I would make
`custom-theme-directory' into a defvar instead of a defcustom, because
we do not want to advertise a package with serious bugs.  I could
install my patch to custom.el with these changes.

My patch to cus-theme.el would document the bugs and tell people it is
currently only meant for developpers wanting to debug the Custom
themes machinery.  Anybody who manages to correct these and other bugs
enough to make Custom Themes safely usable can delete that warning.

New proposed cus-theme.el patch:

===File ~/cus-theme.el-new-diff=============================
*** cus-theme.el	17 Apr 2005 15:28:09 -0500	1.8
--- cus-theme.el	29 Jun 2005 20:32:47 -0500	
***************
*** 31,36 ****
--- 31,48 ----
  (eval-when-compile
    (require 'wid-edit))
  
+ (define-derived-mode custom-new-theme-mode nil "New-Theme"
+   "Major mode for the buffer created by `customize-create-theme'.
+ Do not call this mode function yourself.  It is only meant for internal
+ use by `customize-create-theme'."
+   (set-keymap-parent custom-new-theme-mode-map widget-keymap))
+ (put 'custom-new-theme-mode 'mode-class 'special)
+ 
+ (defvar custom-theme-name)
+ (defvar custom-theme-variables)
+ (defvar custom-theme-faces)
+ (defvar custom-theme-description)
+ 
  ;;;###autoload
  (defun customize-create-theme ()
    "Create a custom theme."
***************
*** 38,52 ****
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (kill-all-local-variables)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
-   (let ((inhibit-read-only t))
-     (erase-buffer))
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
--- 50,81 ----
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (let ((inhibit-read-only t))
!     (erase-buffer))
!   (custom-new-theme-mode)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.
! 
! Just insert the names of all variables and faces you want the theme
! to include.  Then clicking mouse-2 or pressing RET on the [Done] button
! will write a theme file that sets all these variables and faces to their
! current global values.  It will write that file into the directory given
! by the variable `custom-theme-directory', usually \"~/.emacs.d/\".
! 
! To undo all your edits to the buffer, use the [Reset] button.
! 
! *Please Note*: This buffer and the theme files written by it, as well as
! the entire Custom themes feature, are experimental.  They are currently 
! only meant for use by developers who want to debug it.  The most serious
! known bug is that requiring a theme and then setting and saving some option
! through Custom may erase part of your Custom file.  (It erases the options
! for which the theme specifies a value.)  Another, less serious bug is that
! the file created by this buffer will not work for options defined with
! a defcustom that uses :require.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
***************
*** 81,87 ****
       			   (bury-buffer))
       		 "Bury Buffer")
    (widget-insert "\n")
-   (use-local-map widget-keymap)
    (widget-setup))
  
  (defun custom-theme-write (&rest ignore)
--- 110,115 ----
***************
*** 90,95 ****
--- 118,127 ----
  	(variables (widget-value custom-theme-variables))
  	(faces (widget-value custom-theme-faces)))
      (switch-to-buffer (concat name "-theme.el"))
+     (emacs-lisp-mode)
+     (unless (file-exists-p custom-theme-directory)
+       (make-directory (file-name-as-directory custom-theme-directory) t))
+     (setq default-directory custom-theme-directory)
      (setq buffer-file-name (expand-file-name (concat name "-theme.el")))
      (let ((inhibit-read-only t))
        (erase-buffer))
***************
*** 100,106 ****
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
--- 132,139 ----
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")
!     (save-buffer)))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
============================================================

Re: More bugs in Custom themes

[Richard M. Stallman]

    First new bug.  After requiring a theme and then setting and saving
    some option through Custom, all my customizations for all options for
    which the theme specified a value were deleted.

Can you fix that?

    Second new bug: `custom-create-theme' can not handle variables with
    a defcustom that needs a :require and there are a lot of those.

Can you fix that one?

      Until things get fixed (if ever), I would make
    `custom-theme-directory' into a defvar instead of a defcustom, because
    we do not want to advertise a package with serious bugs.

No need.  We won't make the release before fixing this up.

This is an important feature.  We are not going to give up on it.
We're going to *fix it and make it work*, and then we will make
the release.

Please install your changes, except don't install this.

    ! *Please Note*: This buffer and the theme files written by it, as well as
    ! the entire Custom themes feature, are experimental.  They are currently 
    ! only meant for use by developers who want to debug it.  The most serious
    ! known bug is that requiring a theme and then setting and saving some option
    ! through Custom may erase part of your Custom file.  (It erases the options
    ! for which the theme specifies a value.)  Another, less serious bug is that
    ! the file created by this buffer will not work for options defined with
    ! a defcustom that uses :require.\n\n")

Re: More bugs in Custom themes

[Luc Teirlinck]

       First new bug.  After requiring a theme and then setting and saving
       some option through Custom, all my customizations for all options for
       which the theme specified a value were deleted.

   Can you fix that?

       Second new bug: `custom-create-theme' can not handle variables with
       a defcustom that needs a :require and there are a lot of those.

   Can you fix that one?

The current code appears to need a complete rewrite, not just fixing
of a few bugs.  This rewrite has to be done carefully, because the
current attempt at implementation has been superimposed on the entire
Custom code.

   No need.  We won't make the release before fixing this up.

   This is an important feature.  We are not going to give up on it.
   We're going to *fix it and make it work*, and then we will make
   the release.

Custom themes would be a completely new complex feature, not a bug
fix: Custom themes did not come remotely close to working in any prior
Emacs version.  I do not suggest giving up on it, but I do suggest
putting it off until after the 22 release.  Custom themes may be
important, but I do not believe that they are important enough to put
off the release of 22 from a possible 2005 date to some very vague and
very distant future.

I know of various remaining problems concerning the manuals and the
code.  These _really_ need fixing and fixing all of them would be less
difficult and less time consuming than coming up with a workable
Custom themes implementation.  If we fix these first, we can make a
release and we may have a shot at still doing that in 2005.  After
that, we could concentrate on Custom themes.

Correctly implementing Custom themes is complex and will be time-consuming.
People have a need for multiple themes with conflicting settings, that can
be individually removed, so we can not make any simplifying assumptions.
The implementation, once ready, will need thorough testing (people writing
and using themes).  It is impossible to guarantee a time table.

Sincerely,

Luc.

Re: More bugs in Custom themes

[Richard M. Stallman]

    Custom themes would be a completely new complex feature, not a bug
    fix:

They ARE a new feature.  This feature is already in Emacs, it is
important, and I will not stand for giving up on it.  That is the
wrong attitude.

Would you please work on fixing this?  Otherwise we will have to wait
till I have time to do it.  You have been doing great so far, whenever
you decide to fix something rather than say it can't be done.

    The implementation, once ready, will need thorough testing (people writing
    and using themes).  It is impossible to guarantee a time table.

I'm not asking for a guarantee, or a time table.  I'm just asking
someone to fix this feature to work.

Re: More bugs in Custom themes

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Custom themes would be a completely new complex feature, not a bug
>     fix:
>
> They ARE a new feature.  This feature is already in Emacs, it is
> important, and I will not stand for giving up on it.  That is the
> wrong attitude.
>
> Would you please work on fixing this?  Otherwise we will have to wait
> till I have time to do it.  You have been doing great so far, whenever
> you decide to fix something rather than say it can't be done.
>
>     The implementation, once ready, will need thorough testing
>     (people writing and using themes).  It is impossible to
>     guarantee a time table.
>
> I'm not asking for a guarantee, or a time table.  I'm just asking
> someone to fix this feature to work.

It is a new feature, and I think we currently don't use it ourselves
in the sources.  Getting a larger tester and developer base for it
won't happen without it being in the open in a released version (which
it already is in XEmacs, with negligible impact as far as I can see)
_and_ being documented as a feature.

Yes, we might not get it to work under heavy duty in Emacs-22.  But if
we don't start the process of making it somewhat usable now, we won't
get it finished by Emacs-23 either.  Nobody claimed that 22.1 would be
the last release of the 22.x series.  For new _optional_ features, the
goal is to get them in, to get their documentation to a consistent
state, and to make a good stab of getting them working as advertised.

I should be the last to blame Luc if he decides that his personal
tastes, priorities and professional conscience don't lend themselves
to this task: it is not nice to feel responsible for code which one
considers unclean.  And it is always a cheap way out of work to say
"you are better suited for it than I am".  I don't want to go that
route, and I am being much less often helpful than I should because
other projects are also demanding of my time and I don't manage them
and professional deadlines well.

But while I don't want to use this as an excuse for myself, I still
want to express my admiration and gratitude about how often Luc comes
out with a good analysis and working suggestions and patches for
faulty code or documentation that was not written by himself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: More bugs in Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   They ARE a new feature.  This feature is already in Emacs,

There is currently no support for Custom Themes in Emacs that comes
remotely close to working.  The three unfixed bugs I mentioned are
just examples.  As another example, a fourth bug is that when an
option's value is set by a theme, the Customization buffer incorrectly
says "Set and Saved".  It should say that it was set by the theme.  It
does not stop there.  95% of what I try leads to a bug.  In the
remaining 5% of the cases the code gets things right by coincidence,
not by design.  It has no design (except for the "Big Picture", see
below).  It makes no sense to fix the 1001+ bugs in this code.  You
just will have produced 1001+ new ones in the process.  The code in
custom.el needs a really thorough rewrite.  It needs a *design*.  All
of this will take time.

The Custom themes code does not seem to worry too much about little
details like working correctly or how it is supposed to be used by the
user and such.  All it seems to care about is the big picture.  It is
actually possible to understand the big picture but it has some really
bizarre aspects.  Here it is.

First the code obviously gives the impression of trying to implement
Themes support by files of the type cus-theme.el produces.  To really
do that in a bug free and predictable way, the very first thing you
need is a good conflict resolution algorithm.  The code contains none.
The near infinity of bugs is the unavoidable consequence of that.  It
makes a half-hearted and completely incoherent attack at removal of
themes.  Can not be anything else but incoherent: this needs a
conflict resolution algorithm.  Then it tries to implement "hidden
themes", as well as themes requiring, unsetting and hiding other
themes and so on, all while making no attempt whatsoever at getting
the basics right.

>From here on things get completely bizarre.  The Themes code, which is
absolutely saturated with bugs, wants to reimplement Custom to make it
dependent on its own code and "design".  Fortunately, this has not
been completely implemented yet, but the ordinary Custom code appears
to have been at places permeated by the Themes code.  Things get worse
from here.  The envisioned reimplementation of Custom requires a
rewrite of `defvar' and various other basic Emacs primitives.  (No
kidding!  Fortunately this is not implemented yet.  I very much hope
it never will be.)

>From the `custom-declare-variable' docstring:

  DEFAULT is stored as SYMBOL's value in the standard theme.  See
  `custom-known-themes' for a list of known themes.  For backwards
  compatibility, DEFAULT is also stored in SYMBOL's property
  `standard-value'.  At the same time, SYMBOL's property `force-value' is
  set to nil, as the value is no longer rogue."
    ;; Remember the standard setting.  The value should be in the standard
    ;; theme, not in this property.  However, this would require changing
    ;; the C source of defvar and others as well...

First of all, the docstring appears to contain a falsehood.  From the
comment, DEFAULT is not _currently_ stored in the standard theme.  But
the docstring clearly seems to indicate that for full theme support,
this needs to change in the future, requiring a rewrite of defvar and
various other primitives.

This is completely crazy.  Custom themes can be implemented without
redesigning Custom and certainly do not require changing defvar and
tons of other primitives.  What is this madness in the above docstring
and comment?  What Custom themes need is a sensible conflict
resolution algorithm, not a rewrite of defvar!

Sincerely,

Luc.

Re: More bugs in Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   This feature is already in Emacs, it is important, and I will not
   stand for giving up on it.  That is the wrong attitude.

I repeat: I do not suggest giving up on (proper) Themes support.  I
suggest putting it off until after the release.  Are those two equivalent?

   Would you please work on fixing this?

I already fixed six bugs and fixing some of them properly was actually
not as trivial as you suggested.  Four more would be ten.  But it does
not stop there.  As I already said, it makes no sense to fix 1001+
bugs only to create 1001+ others and I will not do that.  I have already
wasted enough time on the nonsense in custom.el.  The Themes code
needs to be rewritten using a proper conflict resolution algorithm and
a proper design.

   You have been doing great so far, whenever you decide to fix
   something rather than say it can't be done.

Just fixing bugs is not doing great if you keep discovering bugs at a
much faster rate than you can solve them and if the lack of design
guarantees the complete impossibility of ever getting the code close to
bugfree (unless it gets a proper design).

It is not very difficult to come up with a good conflict resolution
algorithm (I have outlined one), but it will take time to implement it.

Sincerely,

Luc.

Re: More bugs in Custom themes

[Richard M. Stallman]

    There is currently no support for Custom Themes in Emacs that comes
    remotely close to working.

I'm sure the facts you are stating are accurate, but your emotional
response to the bugs is overstated.  They are just bugs, and they just
need to be fixed.

I'm going to stand by my decision.  We have had too much abandonment
of important features.

Re: More bugs in Custom themes

[Richard M. Stallman]

      The Themes code
    needs to be rewritten using a proper conflict resolution algorithm and
    a proper design.

"A proper design" doesn't identify a specific problem I could address,
but I think we already discussed the proper conflict resolution
method.  What I suggested was that the themes are listed in an order,
and later themes override earlier themes.  Disabling any of the themes
works by getting rid of all of them, then reloading the ones that
remain enabled.  You've already got the function which turns them all
off.

If you think it would be hard to write this, could you tell me which
functions deal with this part of things?  Then I will try.

Re: More bugs in Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   "A proper design" doesn't identify a specific problem I could address,

The very first design decision to be made is: what do we want Custom
Themes to be and how do we want them to be used.

I do not even know what _kind_ of Custom Themes the current code is
trying to implement or how it wants them to be used.  There are no
interactive declarations in the code, so _maybe_ they are only meant
for use in initialization files, to be executed _before_ any
custom-set-{variables,faces} forms.  (_Both_ enabling and unsetting of
themes seems to have to occur before these forms.  No enabling or
unsetting after them, in particular, no _interactive_ enabling or
unsetting.)  The code _seems_ to assume that no two themes (including
the `user' theme, but, of course, excluding the standard theme)
contain customizations for the same variable.

If all these assumptions are strictly adhered to, many of the worst
bugs no longer occur.  There would still be bugs left, but they might
be fixable.

But I seem to have understood that we want something more powerful.
Then I believe that we need a complete rewrite of the current code,
essentially starting from scratch.

I believe I understood that we want to allow multiple Custom Themes,
possibly setting conflicting values for the same option, that can be
_interactively_ (as well as in init files) enabled or disabled in any
order, interspersed with arbitrary saving, setting, and resetting to
standard value, and that we even want to handle interspersed setq's in
a reasonable way.  I seem to have understood that this is what users
want.  I believe that it is possible (but _not_ trivial) to implement
all of that in a clean and intuitive way.  I believe that it has to be
done very carefully.

The current code uses `requiring' to enable Themes.  Re-enabling a
Theme has no effect if it has ever been loaded previously, so it does
not reinstate "clobbered" values.  I believe we agreed that this was a
problem and that user convenience dictates replacing requiring with
unconditional loading as the fundamental Theme enabling mechanism.
This is a second fundamental design departure from the present code.

Then comes the conflict resolution algorithm (I will address that in a
second message).

Sincerely,

Luc.

Re: More bugs in Custom themes

[Luc Teirlinck]

   but I think we already discussed the proper conflict resolution
   method.  What I suggested was that the themes are listed in an order,
   and later themes override earlier themes.

It is a little bit more complex than that.  The user can enable or
disable themes, save options through Custom, set them through Custom,
reset them to standard through Custom and change them using setq.  In
each possible situation, you need to decide how to determine the
actual value, saved-value, theme-value (or theme-face), backup-value
and customized-value.  Maybe the answers are obvious in each case, but
each combination of cases has to be thought about.

I believe that mainly the actual value (the case we have been worrying
about) is not completely trivial.  However, I also have my doubts
about the way the current code handles `saved-value'.  Related to the
latter problem is yet another design decision to be made.  When the
option has been set by a theme, the current code says that it has been
"Saved and set".  I believe that this is unhelpful and confusing and
that it should say instead that it has been set by a theme, preferably
saying which theme.  This probably requires handling saved-value
differently.

   Disabling any of the themes works by getting rid of all of them,
   then reloading the ones that remain enabled.

To me, that seems to be a contorted way to do it.  Also, do not forget
that when the user asks to disable a theme, the value you want to
restore will sometimes be a setq-ed value, thus not associated with any
theme, and that you also have to make sure that your method gets all
stored info right, not just the actual value.

   You've already got the function which turns them all off.

You mean `custom-do-theme-reset'?  That is the very last function I
would want to use, rely on or emulate if I were you.  It indeed turns
them _all_ off, but then _pretends_ that it only turned one off by
just removing one from theme-value (or theme-face).  Looks like a
badly messed up function to me, but since I have no idea what that
code is trying to _accomplish_ (although I know perfectly what it
_does_), I may be wrong.

   If you think it would be hard to write this, could you tell me which
   functions deal with this part of things?  Then I will try.

`custom-do-theme-reset' I am afraid.  Again, I would not take a lot of
my inspiration from that one if I were you.

I believe that a function to properly disable a theme has to be
written from scratch.  But you will probably have to rewrite plenty of
other stuff before you can begin to rewrite that one.

Of course, the function to enable themes will also have to be
rewritten to use unconditional loading instead of requiring, but that
is probably easier.

It is actually my impression that most of the code needs to be
rewritten.  Maybe some stuff can be recycled in one form or another
into the new design.

Sincerely,

Luc.

Re: More bugs in Custom themes

[Richard M. Stallman]

       but I think we already discussed the proper conflict resolution
       method.  What I suggested was that the themes are listed in an order,
       and later themes override earlier themes.

    It is a little bit more complex than that.  The user can enable or
    disable themes, save options through Custom, set them through Custom,
    reset them to standard through Custom and change them using setq.

I suggest that it will be easy to figure out what to do in each of these
cases if we keep in mind the order of priority that these various
actions ought to obey:

   Individual user custom settings.
   Settings from themes (in reverse order of precedence)
   Default values.

As for settings with setq, those should make the variable a rogue, as
now.  When the variable is a rogue, theme operations should not touch
it.

      When the
    option has been set by a theme, the current code says that it has been
    "Saved and set".  I believe that this is unhelpful and confusing and
    that it should say instead that it has been set by a theme, preferably
    saying which theme.

I agree.  I don't think that should be TOO hard.

       Disabling any of the themes works by getting rid of all of them,
       then reloading the ones that remain enabled.

    To me, that seems to be a contorted way to do it.

It is more work for the computer than necessary, but that's what
computers are for.  I proposed this because it should be easy to
implement with simple code.  Thus, we can get it working easily.

However, looking at the code for custom-do-theme-reset, it seems
that I don't have to do much work to make it work right
without reloading loaded themes.  All the data is available
in the theme-value properties.   I just have to rewrite the code
to DTRT in each case.  I've done some of that already.

      Also, do not forget
    that when the user asks to disable a theme, the value you want to
    restore will sometimes be a setq-ed value, thus not associated with any
    theme,

In the scheme as I've proposed it, that cannot happen.

Re: More bugs in Custom themes

[Richard M. Stallman]

I rewrote most of the themes code in custom.el.  I did not have time to
debug it ;-(, but I verified that Emacs still at least builds and
runs.

Whether or not it is bug-free, at least now it should have a clear
design that ought to make fixing any remaining bugs straightforward.
What will take the time now is the testing.  That's what I don't
have time to do now.

Could you please look at the code and see if the design is clear
to you?  If so, could you start testing it and fix bugs that are easy
to fix?

If you find a bug that you can't fix, please send me the test case
and I will fix it.

Re: More bugs in Custom themes

[Luc Teirlinck]

Sorry for the delay in replying to this.

   Could you please look at the code and see if the design is clear
   to you?

I have not had the time to study things in detail, but the design is
certainly clearer than what it used to be.  Very non-trivial questions
remain, like how Custom Themes is going to treat hooks and certain
list variables.  At present, even without Themes, Custom has serious
problems handling these, as we discussed earlier.

   If so, could you start testing it and fix bugs that are easy to
   fix?

Sorry, I do not have much time right now, so if this has to be done
before the release, somebody else will have to do it.

Sincerely,

Luc.

Re: More bugs in Custom themes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Sorry for the delay in replying to this.
>
>    Could you please look at the code and see if the design is clear
>    to you?
>
> I have not had the time to study things in detail, but the design is
> certainly clearer than what it used to be.  Very non-trivial questions
> remain, like how Custom Themes is going to treat hooks and certain
> list variables.  At present, even without Themes, Custom has serious
> problems handling these, as we discussed earlier.

I don't believe it is a good idea trying to make Custom Themes solve
problems that Customize can't solve, such as merging of different
values for options.  Treat that as a problem orthogonal to theme
support, even though theme support makes it more urgent.

I.e. if three active themes all add a function to the the same hook
variable, only the function from the dominating theme will actually be
active.

Re: More bugs in Custom themes

[Richard M. Stallman]

      Very non-trivial questions
    remain, like how Custom Themes is going to treat hooks and certain
    list variables.  At present, even without Themes, Custom has serious
    problems handling these, as we discussed earlier.

There is no need to worry about it--since they did not work cleanly anyway,
the situation now is no worse.

    Sorry, I do not have much time right now, so if this has to be done
    before the release, somebody else will have to do it.

That is too bad.  Can someone else please try to work on this?