Date: Thu, 13 Jan 2000 00:57:36 +0000 From: Nik Clayton <nik@freebsd.org> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: Nik Clayton <nik@freebsd.org>, doc@freebsd.org Subject: Re: Patches I have up my sleeve Message-ID: <20000113005736.F8876@kilt.nothing-going-on.org> In-Reply-To: <19991220070201.C35359@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Mon, Dec 20, 1999 at 07:02:01AM %2B0100 References: <19991218195612.A26001@daemon.ninth-circle.org> <19991219212411.B4452@catkin.nothing-going-on.org> <19991220070201.C35359@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ cc'd to cvs@freebsd.org for some advice ]
On Mon, Dec 20, 1999 at 07:02:01AM +0100, Jeroen Ruigrok/Asmodai wrote:
> >> One, which impacts a lot of files per subdir (faq, handbook, etc) will
> >> remove all excessive whitespaces which were introduced by the sgmlmode
> >> of emacs. I consider this a bug in the editor and should be properly
> >> cleaned up.
> >
> >What sort of excessive whitespace?
>
> Just take a random file from the handbook and you will see a lot of of
> four spaces on line between tags. These lines should be empty instead
> of carrying four spaces. I am really thinking emacs sgml mode messed
> up.
I know exactly how this has happened, having done it myself tonight.
Go to a section of a .sgml file, something like this;
...
</sect3>
</sect2>
<sect2>
<title>A random title</title>
...
Now, suppose you start thinking about adding a new section between the
end of the first </sect2> and the beginning of the next <sect>. So you
move the cursor to be in between them, and hit TAB.
Emacs moves the cursor in four spaces for you, to the correct indentation
level for this.
Now, change your mind, and decide that this section isn't needed, or is
in the wrong location. Move the cursor off the line.
The four spaces remain.
It's not really an editor bug, as there's no way Emacs could guess your
intentions in this case.
From what I can recall, CVS has a mechanism to automatically process
documents before they are committed. If we could have the following
run over every .sgml file just before it's committed, I think we could
solve the problem;
perl -pe 's/^\s+$/\n/'
(reads from STDIN, writes to STDOUT). All this does is convert any line
that contains only plain text to just a single new line. If this is done
every time anything is committed to the tree we take the repository bloat
hit once, and then never have to worry about it again.
I can't think of any circumstances where this would cause problems with
the actual content -- only lines that consist only of white space characters
are going to be affected, and, by their nature, changes to them aren't
going to affect the content -- even in things like <programlisting> lines
that consist only of whitespace aren't important, as long as the notion of
a 'blank' line is retained.
We wouldn't even need to update all the files at once. A file will be
fixed automatically the first time it is committed to after we make this
change.
CVSMeisters -- how feasible would something like this be for implementation
on freefall?
N
--
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000113005736.F8876>