fileio.c "#if 0" block

fileio.c "#if 0" block

[Thien-Thi Nguyen]

i'm doing some emacs-on-vms munging, and see a big "do not disturb"
block in fileio.c.  is that message supposed to be in absolute spirit,
or is it ok to touch that code in the name of maintenance?  i find it
irksome to wrap my head around vms quirks and then turn my back on code
as i apply the fruits of my learning elsewhere.  it is like painting
only the open spaces on the walls and ignoring the trimming, even though
the trimming is behind the curtains [insert week-long house-painting
ordeal story here...]

please cc me in reply; my list subscription is currently fubared.

thi

Re: fileio.c "#if 0" block

[Stefan Monnier]

> i'm doing some emacs-on-vms munging, and see a big "do not disturb"
> block in fileio.c.  is that message supposed to be in absolute spirit,
> or is it ok to touch that code in the name of maintenance?

I have no idea what "do not disturb" message you're referring to.
But as a general rule, there's no taboo in the code, so you can change
anything you want.  OTOH if there's such a sign, it probably indicates that
there's something tricky going on; more than meets the eye.


        Stefan

Re: fileio.c "#if 0" block

[Richard Stallman]

    i'm doing some emacs-on-vms munging, and see a big "do not disturb"
    block in fileio.c.

I don't know what you mean; I searched for the string
"do not disturb" but did not find it in fileio.c.
Would you please show me the message you're talking about?

Re: fileio.c "#if 0" block

[Thien-Thi Nguyen]

   From: Richard Stallman <rms@gnu.org>
   Date: Fri, 04 Mar 2005 18:45:29 -0500

   Would you please show me the message you're talking about?

sorry, i did not quote the block precisely.  the block begins w/:

#if 0
/* PLEASE DO NOT DELETE THIS COMMENTED-OUT VERSION!

(and goes on to surround a "DEAFUN" for Fexpand_file_name.)

thi

Re: fileio.c "#if 0" block

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@surf.glug.org>
> Date: Sat, 05 Mar 2005 12:50:20 +0100
> Cc: emacs-devel@gnu.org
> 
> sorry, i did not quote the block precisely.  the block begins w/:
> 
> #if 0
> /* PLEASE DO NOT DELETE THIS COMMENTED-OUT VERSION!
> 
> (and goes on to surround a "DEAFUN" for Fexpand_file_name.)

If that's the code fragment you were referring to, then the
explanation why it is disabled but left in the sources is right there
in the comment, viz:

   This is the old version of expand-file-name, before it was thoroughly
   rewritten for Emacs 10.31.  We leave this version here commented-out,
   because the code is very complex and likely to have subtle bugs.  If
   bugs _are_ found, it might be of interest to look at the old code and
   see what did it do in the relevant situation.

   Don't remove this code: it's true that it will be accessible via CVS,
   but a few years from deletion, people will forget it is there.  */

(I think that "10.31" is a typo: it should be "19.31".)

Given this very clear (IMHO) explanation, I don't understand your
original gripe about it:

> i find it irksome to wrap my head around vms quirks and then turn my
> back on code as i apply the fruits of my learning elsewhere.

Can you explain what you meant by that, now that you know why the old
code was left in the sources, rather than deleted?

> please cc me in reply

Done (although it should be the default of any decent mail software).

> my list subscription is currently fubared.

I'm the list administrator, so if you need help with that, please mail
me privately.

Re: fileio.c "#if 0" block

[Richard Stallman]

    sorry, i did not quote the block precisely.  the block begins w/:

    #if 0
    /* PLEASE DO NOT DELETE THIS COMMENTED-OUT VERSION!

    (and goes on to surround a "DEAFUN" for Fexpand_file_name.)

Now I see it.

What is the problem?  That is just a comment.  Preserving that comment
should not interfere with the changes you want to make.

Re: fileio.c "#if 0" block

[Thien-Thi Nguyen]

   From: "Eli Zaretskii" <eliz@gnu.org>
   Date: Sat, 05 Mar 2005 19:20:17 +0200

   Given this very clear (IMHO) explanation, I don't understand your
   original gripe about it: [...] Can you explain what you meant by
   that, now that you know why the old code was left in the sources,
   rather than deleted?

as part of the emacs under vms effort, i'm addressing some of the
"subtle bugs" (that are related to vms) in Fexpand_file_name, by
studying the current behavior, forming a mental model of the correct
behavior and making the necessary changes.  for completeness, i would
prefer to apply these bugfixes to all instances of the bug that i can
find, whether in one function or in many.

i get the feeling that modifying the #if-0'ed out Fexpand_file_name,
however, goes against the intent of preserving it in some kind of
pristine form.  i can see a value in leaving it completely untouched as
a historical snapshot (certainly, it is less work to completely ignore
it).  my griping was an expression of inner conflict at allowing bit rot
to flourish unchecked, and not completing the job in some sense.

but having written this, i've overcome that internal conflict (laziness
wins) -- i'll leave that code alone for someone else to munge, and work
on something else.

thi

Re: fileio.c "#if 0" block

[Thien-Thi Nguyen]

   From: Richard Stallman <rms@gnu.org>
   Date: Sat, 05 Mar 2005 19:40:54 -0500

   What is the problem?  That is just a comment.  Preserving that
   comment should not interfere with the changes you want to make.

i was fretting about whether or not to apply (vms-specific) bugfixes to
both versions of Fexpand_file_name.  but now i've decided not to bother
w/ the #if-0'ed version.

thi

Re: fileio.c "#if 0" block

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@surf.glug.org>
> CC: emacs-devel@gnu.org
> Date: Sun, 06 Mar 2005 02:25:11 +0100
> 
> as part of the emacs under vms effort, i'm addressing some of the
> "subtle bugs" (that are related to vms) in Fexpand_file_name, by
> studying the current behavior, forming a mental model of the correct
> behavior and making the necessary changes.  for completeness, i would
> prefer to apply these bugfixes to all instances of the bug that i can
> find, whether in one function or in many.

There's no need to change anything inside the ifdef'ed code, IMHO:
it's there only to present the original design of Fexpand_file_name,
which is quite hard to glean from the current convoluted code.

Re: fileio.c "#if 0" block

[Thien-Thi Nguyen]

   From: "Eli Zaretskii" <eliz@gnu.org>
   Date: Sun, 06 Mar 2005 06:52:13 +0200

   There's no need to change anything inside the ifdef'ed code, IMHO:
   it's there only to present the original design of Fexpand_file_name,
   which is quite hard to glean from the current convoluted code.

ok, i will leave it alone.

thi

Re: fileio.c "#if 0" block

[Richard Stallman]

    i was fretting about whether or not to apply (vms-specific) bugfixes to
    both versions of Fexpand_file_name.  but now i've decided not to bother
    w/ the #if-0'ed version.

That's the right way to deal with it.