convert regex.c, strftime.c mktime.c to standard C

convert regex.c, strftime.c mktime.c to standard C

[Dan Nicolaescu]

These files currently get -Wold-function-definition warnings.
They were not converted in the first place because they are imported
from other projects.

The last two come from gnulib, but gnulib is so different now that
updating those files is not feasible, gnulib support would need to be
redone from scratch.

Not sure how close regex.c is to upstream, but the extra differences
from converting to standard C won't be too bad.

Re: convert regex.c, strftime.c mktime.c to standard C

[Stefan Monnier]

> Not sure how close regex.c is to upstream, but the extra differences
> from converting to standard C won't be too bad.

AFAIK regex.c's upstream doesn't exist any more.


        Stefan

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    The last two come from gnulib, but gnulib is so different now that
    updating those files is not feasible, gnulib support would need to be
    redone from scratch.

It would be a good idea to update to the most recent version of
strftime.c and mktime.c.  Surely this is not very hard, even if it
requires rewriting the relevant parts of Emacs from zero.

regexp.c might be harder.  Would Emacs work with the current
regex.c from gnulib, or does it lack some features added for Emacs?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: convert regex.c, strftime.c mktime.c to standard C

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

>     The last two come from gnulib, but gnulib is so different now that
>     updating those files is not feasible, gnulib support would need to be
>     redone from scratch.
>
> It would be a good idea to update to the most recent version of
> strftime.c and mktime.c.  Surely this is not very hard, even if it
> requires rewriting the relevant parts of Emacs from zero.

The gnulib maintainer said it's not trivial, the gnulib infrastructure
has changed.  It might be worth doing it, but until we get a volunteer to do it...

> regexp.c might be harder.  Would Emacs work with the current
> regex.c from gnulib, or does it lack some features added for Emacs?

Don't know.

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    > It would be a good idea to update to the most recent version of
    > strftime.c and mktime.c.  Surely this is not very hard, even if it
    > requires rewriting the relevant parts of Emacs from zero.

    The gnulib maintainer said it's not trivial, the gnulib infrastructure
    has changed.

"The gnulib infrastructure has changed" is very general.
What is the change that makes this difficult?

My suggestion is to get the latest version of these facilities
from gnulib and change Emacs to use them.  Why would any change
in gnulib interfere with that?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: convert regex.c, strftime.c mktime.c to standard C

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

>     > It would be a good idea to update to the most recent version of
>     > strftime.c and mktime.c.  Surely this is not very hard, even if it
>     > requires rewriting the relevant parts of Emacs from zero.
>
>     The gnulib maintainer said it's not trivial, the gnulib infrastructure
>     has changed.
>
> "The gnulib infrastructure has changed" is very general.
> What is the change that makes this difficult?

No idea, that's what I was told.

> My suggestion is to get the latest version of these facilities
> from gnulib and change Emacs to use them.  Why would any change
> in gnulib interfere with that?

AFAIU getting "the latest version of these facilities from gnulib" is
not very simple...  We'd need to find a volunteer to do it.  It's not
a very rewarding job, what we have now works and it hasn't changed in
years...

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    AFAIU getting "the latest version of these facilities from gnulib" is
    not very simple...  We'd need to find a volunteer to do it.

Why do you think so?  It ought to be trivial to find the current
gnulib files that do these jobs.

Changing Emacs to use those current gnulib files would be some work,
but should not be a lot.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: convert regex.c, strftime.c mktime.c to standard C

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 19 Nov 2010 01:16:54 -0500
> Cc: emacs-devel@gnu.org
> 
>     AFAIU getting "the latest version of these facilities from gnulib" is
>     not very simple...  We'd need to find a volunteer to do it.
> 
> Why do you think so?  It ought to be trivial to find the current
> gnulib files that do these jobs.
> 
> Changing Emacs to use those current gnulib files would be some work,
> but should not be a lot.

Finding strftime.c in gnulib is indeed trivial, but making it part of
Emacs that compiles on all supported platforms is not just "some
work", it's a formidable job, IMO.  I suggest you download the latest
gnulib and read the instructions for how to build it or its parts, and
also look at the scripts and source files involved to appreciate the
job at hand.

The build system used by gnulib is not just Makefile.in and
config.h.in.  It is one of the more contrived build systems I've ever
seen, and it requires to run the configury stuff on each supported
platform, to get all the gazillions of preprocessor symbols defined
correctly.  It is a lot of mundane, thankless work.  I can easily
understand why Dan is not volunteering, and I don't believe we will
easily find a volunteer, either.

Re: convert regex.c, strftime.c mktime.c to standard C

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Finding strftime.c in gnulib is indeed trivial, but making it part of
> Emacs that compiles on all supported platforms is not just "some
> work", it's a formidable job, IMO.
>
> The build system used by gnulib is not just Makefile.in and
> config.h.in.  It is one of the more contrived build systems I've ever
> seen, and it requires to run the configury stuff on each supported
> platform, to get all the gazillions of preprocessor symbols defined
> correctly.

According to the Gnulib website,

  Gnulib takes a different approach. Its components are intended to be
  shared at the source level, rather than being a library that gets
  built, installed, and linked against. Thus, there is no distribution
  tarball; the idea is to copy files from Gnulib into your own source
  tree.

So if we're having trouble doing exactly what Gnulib was designed for,
something is pretty badly wrong.

Re: convert regex.c, strftime.c mktime.c to standard C

[Sam Steingold]

> * Chong Yidong <plq@fghcvqpuvpxra.pbz> [2010-11-19 11:58:12 -0500]:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Finding strftime.c in gnulib is indeed trivial, but making it part of
>> Emacs that compiles on all supported platforms is not just "some
>> work", it's a formidable job, IMO.
>>
>> The build system used by gnulib is not just Makefile.in and
>> config.h.in.  It is one of the more contrived build systems I've ever
>> seen, and it requires to run the configury stuff on each supported
>> platform, to get all the gazillions of preprocessor symbols defined
>> correctly.
>
> According to the Gnulib website,
>
>   Gnulib takes a different approach. Its components are intended to be
>   shared at the source level, rather than being a library that gets
>   built, installed, and linked against. Thus, there is no distribution
>   tarball; the idea is to copy files from Gnulib into your own source
>   tree.
>
> So if we're having trouble doing exactly what Gnulib was designed for,
> something is pretty badly wrong.

I use gnulib from clisp and I am "reasonably happy".

1. Use gnulib-tool script to extract the gnulib files and put them in
the right place. This process is geared towards projects which use
automake; clisp does not, however, it works okay anyway.

2. Beware of the "dependency creep": asking for a couple of files might
pull in a dozen. I.e., the best way to integrate with gnulib is to
delegate _all_ portability issues to it. The downside is that you are
likely to end up distributing most of gnu libc with emacs; you have to
monitor closely what gnulib is pulling in and bitch vociferously to the
gnulib people if you think that the dependency is unjustified.

PS. I am _not_ volunteering to hook gnulib into emacs.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
http://www.memritv.org http://pmw.org.il http://palestinefacts.org
http://openvotingconsortium.org http://thereligionofpeace.com http://ffii.org
People hear what they want to hear and discard the rest.

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> According to the Gnulib website,
>
>   Gnulib takes a different approach. Its components are intended to be
>   shared at the source level, rather than being a library that gets
>   built, installed, and linked against. Thus, there is no distribution
>   tarball; the idea is to copy files from Gnulib into your own source
>   tree.
>
> So if we're having trouble doing exactly what Gnulib was designed for,
> something is pretty badly wrong.

I just copied over strftime.{ch} from gnulib and put it into emacs/src
and compiled, and it didn't complain when compiling.  And Emacs still
works.  However, I have no idea where strftime is being called from in
Emacs -- grepping only shows it being called from msdos.c?  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2010 18:15:05 +0100
> 
> I just copied over strftime.{ch} from gnulib and put it into emacs/src
> and compiled, and it didn't complain when compiling.

You are being lucky.  Are you sure all the preprocessor macros DTRT?

> However, I have no idea where strftime is being called from in
> Emacs -- grepping only shows it being called from msdos.c?  

Your grepping was too sophisticated.  Try a simple fgrep, and you will
see it.

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You are being lucky.  Are you sure all the preprocessor macros DTRT?

Nope.

> Your grepping was too sophisticated.  Try a simple fgrep, and you will
> see it.

I'm seeing emacs_strftimeu (which is apparently a wrapper around
my_strftime and stuff), but I've so far been unable to see where it's
actually being used.  Any Lisp-level functions that end up calling this? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2010 19:02:19 +0100
> 
> I'm seeing emacs_strftimeu (which is apparently a wrapper around
> my_strftime and stuff), but I've so far been unable to see where it's
> actually being used.  Any Lisp-level functions that end up calling this? 

format-time-string (defined on editfns.c) calls emacs_memftimeu, which
calls emacs_strftimeu.

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> format-time-string (defined on editfns.c) calls emacs_memftimeu, which
> calls emacs_strftimeu.

(format-time-string "%Y-%m-%d %H:%M:%S %Z")
=> "2010-11-19 19:49:19 CET"

Seems like it's working...

I've had a peek at the other to things mentioned, but mktime.c doesn't
seem to be compiled at all for me, and regex.c has been split up into
about six other files, and the emacs-specific things there seem to have
disappeared (or been moved around).  I've only done a cursory check.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've had a peek at the other to things mentioned, but mktime.c doesn't
> seem to be compiled at all for me, and regex.c has been split up into
> about six other files, and the emacs-specific things there seem to have
> disappeared (or been moved around).  I've only done a cursory check.

Poking about a bit more, it seems like the regex stuff in gnulib is
quite different from the stuff in regex.c in Emacs.  There's no function
like regex_compile in gnulib (but re_compile_pattern), for instance, so
it's not a straight drop-in replacement, in any case.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

I managed to provoke Emacs into using emacs_mktime instead of mktime,
and dropped the gnulib mktime* files into src, and it seems to work fine:

(format-time-string "%Y-%m-%d %H:%M:%S %Z" (encode-time 10 20 12 10 11 2010))
"2010-11-10 12:20:10 CET"

Of course, I have absolutely no idea whether this works on a different
platform, but strftime/mktime certainly don't look very daunting...

Should I just check it in?  It's trivial enough to revert if it
breaks...  everything...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Sven Joachim]

On 2010-11-19 19:02 +0100, Lars Magne Ingebrigtsen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> You are being lucky.  Are you sure all the preprocessor macros DTRT?
>
> Nope.
>
>> Your grepping was too sophisticated.  Try a simple fgrep, and you will
>> see it.
>
> I'm seeing emacs_strftimeu (which is apparently a wrapper around
> my_strftime and stuff), but I've so far been unable to see where it's
> actually being used.  Any Lisp-level functions that end up calling this? 

Without even looking at the code, format-time-string seems to be an
obvious candidate.

Sven

Re: convert regex.c, strftime.c mktime.c to standard C

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> However, I have no idea where strftime is being called from in Emacs
> -- grepping only shows it being called from msdos.c?

Why didn't you look in editfns.c?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: convert regex.c, strftime.c mktime.c to standard C

[Bruno Haible]

Eli Zaretskii wrote:
> The build system used by gnulib is not just Makefile.in and
> config.h.in.  ... it requires to run the configury stuff on each supported
> platform, to get all the gazillions of preprocessor symbols defined
> correctly.

This statement is very misleading. The build system used by gnulib is
based on autoconf macros and Makefile.am. The developers of gnulib test
it on various platforms. But as a user of gnulib, you don't need to do
this. gnulib did it for you already.

Maybe you meant that retrofitting gnulib's code into the Emacs build
system with src/s/ and src/m/ would require to run the configury stuff
on each supported platform. Sure, that would be the case if you intend
to reuse just the C code of gnulib and ignore the corresponding autoconf
macros. But that's not the way gnulib is meant to be used.

The recommended approach for using gnulib (in the case of Emacs,
which doesn't use Automake so far) is create a new subdirectory, say
gnulib-lib/, with a Makefile.am, and run 'gnulib-tool', telling it to
import a set of modules (such as 'strftime') into that directory.
gnulib-tool prints a set of instructions for adjusting configure.ac
(or configure.in). If you follow these instructions, the resulting code
configures, compiles, links, and runs fine on all supported platforms.

Note that DJGPP is not a supported platform of gnulib. If you want DJGPP
support, you may need to work with the gnulib developers in a constructive
way.

> Finding strftime.c in gnulib is indeed trivial, but making it part of
> Emacs that compiles on all supported platforms is not just "some
> work", it's a formidable job, IMO.

For someone who's familiar with gnulib, it should be the job of 1 hour,
and for someone not familiar with gnulib, it should be done in 1-2 days.

Bruno

Re: convert regex.c, strftime.c mktime.c to standard C

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Date: Sat, 20 Nov 2010 12:57:03 +0100
> 
> Maybe you meant that retrofitting gnulib's code into the Emacs build
> system with src/s/ and src/m/ would require to run the configury stuff
> on each supported platform.

Of course, that's what I meant.  What else could I possibly mean?

> Note that DJGPP is not a supported platform of gnulib.

And neither is MinGW, AFAICS, at least not without using MSYS, which
is not how Emacs works.

Re: convert regex.c, strftime.c mktime.c to standard C

[Bruno Haible]

Eli,

> > Maybe you meant that retrofitting gnulib's code into the Emacs build
> > system with src/s/ and src/m/ would require to run the configury stuff
> > on each supported platform.
> 
> Of course, that's what I meant.

This is not the documented way how gnulib is meant to be used. The way
to use gnulib is to take its code and autoconf macros as a unit, for
each module.

Emacs uses an Autoconf configure.in. Autoconf makes it unnecessary to
"run the configury stuff on each supported platform, to get all the
gazillions of preprocessor symbols defined correctly". The approach you
describe is the one in use before Autoconf came along.

> > Note that DJGPP is not a supported platform of gnulib.
> 
> And neither is MinGW, AFAICS, at least not without using MSYS, which
> is not how Emacs works.

Not true. mingw is supported by about 98% of gnulib (see the documentation
at http://www.gnu.org/software/gnulib/manual/). And, as you might know,
there are 3 ways to build binaries for mingw:
  - using MSYS,
  - from Cygwin,
  - cross-compiling from Unix.
If you don't like one of the three, just choose among the other two approaches.
Several packages that rely on gnulib have build instructions for mingw.
Such as this one:
<http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=README.woe32;hb=HEAD>

Bruno

Re: convert regex.c, strftime.c mktime.c to standard C

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Date: Sat, 20 Nov 2010 16:43:52 +0100
> Cc: emacs-devel@gnu.org
> 
> > > Maybe you meant that retrofitting gnulib's code into the Emacs build
> > > system with src/s/ and src/m/ would require to run the configury stuff
> > > on each supported platform.
> > 
> > Of course, that's what I meant.
> 
> This is not the documented way how gnulib is meant to be used. The way
> to use gnulib is to take its code and autoconf macros as a unit, for
> each module.
> 
> Emacs uses an Autoconf configure.in. Autoconf makes it unnecessary to
> "run the configury stuff on each supported platform, to get all the
> gazillions of preprocessor symbols defined correctly". The approach you
> describe is the one in use before Autoconf came along.

I really don't understand what you are saying.  The configury needs to
be run, but it doesn't?

What I meant is that the only documented way of building modules from
gnulib is through gnulib-tool, which is a Unix shell script.  What
exactly it does is not explained anywhere in a way that could be used
to manually collect the module's dependencies, nor did I find an
easily accessible information about how to do that without
gnulib-tool.  The only clearly documented way of getting and building
a module is what is in "Initial import", which doesn't say a word
about how to do this stuff without gnulib-tool.

Then there's the Makefile.am stuff; Emacs doesn't use that.

It's probably okay to run all this on several Unix platforms (I only
tried on GNU/Linux, so I wouldn't know), but the task of figuring out
this on Windows is daunting, even after reading the whole of
gnulib-tool.

In this thread, we are talking about replacing 3 modules in Emacs with
their newer versions.  These modules constitute 5 files in the Emacs
source tree, and have a few tests for them in configure.in.  Ideally,
the job of replacing them would mean:

  . replace the files with their new versions
  . add additional files that these 5 depend on, if any; modify
    src/Makefile.in as needed
  . maybe add some tests to configure.in
  . figure out what is needed for non-Posix platforms
  . test on supported platforms

If I would volunteer to do this job, how would I go about it?  And
where do I find some documentation that would help me do it?

Now, maybe I missed something in the docs.  Or maybe someone who knows
a lot about how the gnulib build process works can find their way
through all this.  But please don't make it sound like an easy job for
Joe Random Hacker.

> > And neither is MinGW, AFAICS, at least not without using MSYS, which
> > is not how Emacs works.
> 
> Not true. mingw is supported by about 98% of gnulib (see the documentation
> at http://www.gnu.org/software/gnulib/manual/).

A more specific pointer would be appreciated.  The manual is very
large, but there's no "MinGW" in the index, nor "Windows", nor even
"Installation".  What I found in "Initial import" says nothing about
building on Windows.

> And, as you might know, there are 3 ways to build binaries for mingw:
>   - using MSYS,
>   - from Cygwin,
>   - cross-compiling from Unix.

Emacs on Windows builds natively with MinGW, it doesn't use any of the
above.  See nt/INSTALL in the Emacs distribution.  There's a single
configure.bat file, a config.nt file that gets edited into
src/config.h and a bunch of makefile.w32-in (which only exist because
we still support NMake in addition to GNU Make).  The build itself
requires only 3 programs that don't exist on a Windows box: rm, mv,
and cp (and makeinfo, if you build development sources out of the bzr
repo).  That's it.

> Several packages that rely on gnulib have build instructions for mingw.
> Such as this one:
> <http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=README.woe32;hb=HEAD>

Which says to install Cygwin.  No, thanks.  We don't want to ask
Windows users to do that, just to build Emacs with MinGW.

Re: convert regex.c, strftime.c mktime.c to standard C

[Bruno Haible]

Eli Zaretskii wrote:
> What I meant is that the only documented way of building modules from
> gnulib is through gnulib-tool, which is a Unix shell script.  What
> exactly it does is not explained anywhere in a way that could be used
> to manually collect the module's dependencies, nor did I find an
> easily accessible information about how to do that without
> gnulib-tool.

In theory, you could do everything by hand, by looking at the fields
of the module description of every module.
<http://www.gnu.org/software/gnulib/manual/html_node/Module-description.html>
But it gets very tedious, and moreover, every small mistake that you make
in this process likely becomes a portability problem that you discover
only after you've rolled your release tarball. Paul Eggert maintained
coreutils a while like this, then switched over to using gnulib-tool.
I did the same in gettext. Sam Steingold in clisp. It's just not
recommendable to do it by hand.

> In this thread, we are talking about replacing 3 modules in Emacs with
> their newer versions.  These modules constitute 5 files in the Emacs
> source tree, and have a few tests for them in configure.in.  Ideally,
> the job of replacing them would mean:
> 
>   . replace the files with their new versions
>   . add additional files that these 5 depend on, if any; modify
>     src/Makefile.in as needed
>   . maybe add some tests to configure.in
>   . figure out what is needed for non-Posix platforms
>   . test on supported platforms

I can only recommend: Don't do it by hand. Use gnulib-tool, or don't
do it at all.

> Then there's the Makefile.am stuff; Emacs doesn't use that.

It is possible to use a Makefile.am in a subdirectory of a package
that otherwise only uses Makefile.in. An example of this package layout
is GNU libiconv:
  http://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=tree
  http://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=tree;f=srclib;hb=HEAD

> It's probably okay to run all this on several Unix platforms (I only
> tried on GNU/Linux, so I wouldn't know), but the task of figuring out
> this on Windows is daunting

The use of a build environment that is not capable of executing 'configure'
scripts is indeed an impediment; see my other mail about this.

> > Several packages that rely on gnulib have build instructions for mingw.
> > Such as this one:
> > <http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=README.woe32;hb=HEAD>
> 
> Which says to install Cygwin.  No, thanks.  We don't want to ask
> Windows users to do that, just to build Emacs with MinGW.

You have to be aware of the tradeoff: Insisting on a Windows build environment
that cannot execute 'configure' scripts is an impediment to the use of Automake,
Gnulib, Libtool, and thus a penalty for the project as a whole. I can't decide
for the Emacs developers community, but for libiconv, gettext, and libunistring
I decided that making good use of Automake and Gnulib was more important than
details of build instructions for Windows binaries.

Bruno

Re: convert regex.c, strftime.c mktime.c to standard C

[David De La Harpe Golden]

On 20/11/10 15:43, Bruno Haible wrote:

> Emacs uses an Autoconf configure.in.

Not on all platforms, no. e.g. w32 emacs doesn't.

>>> Note that DJGPP is not a supported platform of gnulib.
>>
>> And neither is MinGW, AFAICS, at least not without using MSYS, which
>> is not how Emacs works.
>
> Not true. mingw is supported by about 98% of gnulib (see the documentation
> at http://www.gnu.org/software/gnulib/manual/). And, as you might know,
> there are 3 ways to build binaries for mingw:
>    - using MSYS,
>    - from Cygwin,
>    - cross-compiling from Unix.

You don't need MSYS to build w32 binaries _with_ the mingw toolchain 
(you do need it to build msys and mingw tools and mingwports themselves, 
but that's a different matter to building w32 stuff with mingw).

(cygwin emacs is a also different matter, that's most successfully built 
with cygwin proper of course...)

In fact, the MSYS variants of various command line tools have odd 
handling of some things (sort of like a cut-down cygwin, but compatible 
with neither modern cygwin nor native w32 conventions) compared to the 
more w32-native-ised gnuwin32 tools, say.

I fairly recently slogged through building w32 emacs under WINE and 
mistakenly trying to build with MSYS stuff hanging around cost me a 
couple of days of incomprehensible (for me, as someone not especially 
familiar with or at all a fan of w32) errors.

The MSYS variant tools presently confuse w32 emacs during build (and I 
would guess potentially at run time too).  Now, in principle emacs could 
include some detection of MSYS variant tools and support, but IMO you'd 
be almost getting into a third port of emacs to windows (the line would 
be blurry), i.e.

. cygwin emacs:
   exists
   basically just a unix type port if quirkier than most
   built with cygwin gcc port
   uses autoconf

. w32 emacs
   exists
   native w32 port
   usually built with mingw (remember, used to build with MSVC++ too)
   does not use autoconf

. msys emacs
   hypothetical
   mingwPORT type port
   would build with mingw and msys
   presumably would use msys' autoconf

Re: convert regex.c, strftime.c mktime.c to standard C

[Bruno Haible]

David De La Harpe Golden wrote:
> > Emacs uses an Autoconf configure.in.
> 
> Not on all platforms, no. e.g. w32 emacs doesn't.

When you have a single platform like this, which is not built by executing
'configure', the maintainer has to keep lists of preprocessor defines or
a prefabricated config.h up-to-date, manually. This is tedious, and this
would be the even more tedious when you start using gnulib, to the point
where it becomes no more manageable.

For libiconv and gettext, at the moment when the packages started to use
gnulib, I had to change the build instructions for the Windows port to
recommend mingw + configure (instead of dedicated config.h and Makefiles
for that platform).

> > there are 3 ways to build binaries for mingw:
> >    - using MSYS,
> >    - from Cygwin,
> >    - cross-compiling from Unix.
> 
> You don't need MSYS to build w32 binaries _with_ the mingw toolchain

Yes, but the point is to use a build environment that can execute configure
scripts.

With just a mingw-gcc, mingw-binutils, and 'make', you can build Windows
binaries, but you have to update a config.h.w32 each time something in the
autoconfiguration changes, and you have to update the Makefile.in -> Makefile
conversion facility each time a new AC_SUBSTed variable used. This
maintenance burden goes away if you use a build environment that can execute
configure scripts.

gnulib uses a *lot* of autoconfiguration, and the set of AC_SUBSTed variables
changes every week. That

> (cygwin emacs is a also different matter, that's most successfully built 
> with cygwin proper of course...)

Sure, that's a different beast. I'm talking about using Cygwin as an
environment for building mingw binaries.

> In fact, the MSYS variants of various command line tools have odd 
> handling of some things (sort of like a cut-down cygwin, but compatible 
> with neither modern cygwin nor native w32 conventions) compared to the 
> more w32-native-ised gnuwin32 tools, say.

Yes. For this reason, I'd recommend Cygwin over MSYS, as an environment
for building mingw binaries.

> . w32 emacs
>    exists
>    native w32 port
>    usually built with mingw (remember, used to build with MSVC++ too)
>    does not use autoconf

What I'm suggesting, in order to be able to use more of autoconf, automake,
and gnulib, is:

  . w32 emacs
    native w32 port
    usually built with mingw (semi-cross from Cygwin, or cross from a glibc
    system)
    uses autoconf

About MSVC++ builds: With recent (unreleased) Autoconf, the 'compile' script
can work directly with the MSVC 'cl' command. So, soon, you will also be
able to build native Windows binaries of programs with MSVC by using the
regular autoconf generated configure script.

Bruno

Re: convert regex.c, strftime.c mktime.c to standard C

[Bruno Haible]

Richard Stallman asked:
> regexp.c might be harder.  Would Emacs work with the current
> regex.c from gnulib, or does it lack some features added for Emacs?

Emacs appears to rely on an efficient re_search_2 and re_match_2 function.
Whereas the implementation of re_search_2 and re_match_2 in glibc and gnulib
concatenates the two given strings in a single malloc'ed area, performs the
search, and then frees the malloc'ed area. Depending on the typical sizes of
strings that are passed to re_search_2 and re_match_2, this may or may not
be a performance killer.

Bruno

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    Whereas the implementation of re_search_2 and re_match_2 in glibc and gnulib
    concatenates the two given strings in a single malloc'ed area, performs the
    search, and then frees the malloc'ed area.

That would be totally useless for Emacs.  Copying the whole Emacs
buffer in that way just once could cause a delay big enough for
the user to see.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> That would be totally useless for Emacs.  Copying the whole Emacs
> buffer in that way just once could cause a delay big enough for
> the user to see.

If typical code snippets like

(while (re-search-forward "..." nil t) ...)

copies the entire buffer for each re-search-forward call, then it's not
something that Emacs could use, I think.

But I wonder what the performance impact would be if functions like
`re-search-forward' just moved the gap somewhere (to before point, for
instance?).  Then the regex functions could just work directly on the
buffer, but without knowledge of the gap.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    But I wonder what the performance impact would be if functions like
    `re-search-forward' just moved the gap somewhere (to before point, for
    instance?).  Then the regex functions could just work directly on the
    buffer, but without knowledge of the gap.  

Most editing is localized.  With a large buffer, it would be a big
inefficiency to move the gap far away for each search, then move it back
to change the buffer.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: convert regex.c, strftime.c mktime.c to standard C

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Most editing is localized.  With a large buffer, it would be a big
> inefficiency to move the gap far away for each search, then move it back
> to change the buffer.

Yes, it would most likely be a performance hit, but it might not be
prohibitive.

If the typical use case is

(while (re-search-forward "foo" nil t)
  (insert "bar"))

or something, and the `re-search-forward' moved the gap to before point,
it's not obvious (at least not to me :-) how big the performance hit
would be, since the `insert' most likely moves the gap, anyway.

(And only the first `re-search-forward' would move the gap, since after
moving it to before point, no further gap moves would be necessary.)

If the new, gapless regex code is much faster than the old, gap-aware
regex code, then this might be a net win.  Or not.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convert regex.c, strftime.c mktime.c to standard C

[Lennart Borgman]

On Mon, Nov 22, 2010 at 5:45 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
>
> If the new, gapless regex code is much faster than the old, gap-aware
> regex code, then this might be a net win.  Or not.

I have a question "in the opposite direction".

As you perhaps know I have written some code for multiple major modes
in a buffer, mumamo.el in nXhtml. Different chunks of the buffer have
different major modes. Some part of mumamo.el becomes quite complex
and is easily broken because it is hard to stop a major mode from
looking in chunks that are for other major modes.

Examples of this problem are parsers of all kinds that belongs to a
certain major mode.

This is quite hard to fix and I have been thinking about a low level
change where you could "hide" all the chunks has a different major
mode when the major mode in question for a parser etc.

Fixing the regexp code looked like something that could be
troublesome. Do you have any opinion about if this is doable and if it
would slow down the code very much when such a restriction as above
would be active?

Islands and streams [Was: convert regex.c, .... to standard C]

[Alan Mackenzie]

Hi, Lennart!

On Mon, Nov 22, 2010 at 05:59:23PM +0100, Lennart Borgman wrote:
> On Mon, Nov 22, 2010 at 5:45 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> As you perhaps know I have written some code for multiple major modes
> in a buffer, mumamo.el in nXhtml. Different chunks of the buffer have
> different major modes. Some part of mumamo.el becomes quite complex and
> is easily broken because it is hard to stop a major mode from looking
> in chunks that are for other major modes.

> Examples of this problem are parsers of all kinds that belongs to a
> certain major mode.

> This is quite hard to fix and I have been thinking about a low level
> change where you could "hide" all the chunks has a different major
> mode when the major mode in question for a parser etc.

So have I, vaguely.  Here are my thoughts:

Emacs's syntax and movement routines should be enhanced to handle
"islands".  An @dfn{island} is a contiguous region of text where a
major mode different from the surrounding text's is in force.  It might
be feasible to mark an island with syntax-table text props, it might not.
Islands can be nested.

Movement commands normally don't recognise islands as anything unusual,
and just move into/out of them.  By binding variable "respect-islands" to
non-nil, any movement command would skip over any islands it encountered,
and such commands could not move point out of an island.

Several islands with the same major mode can by chained together as a
@dfn{stream}.  When respect-islands is non-nil, movement commands can
jump over the "ocean" to the next/previous island in the chain.

Some other Emacs features, such as font locking, would need enhancement.

POSSIBLE USES OF ISLANDS:
(i) In mumamo.  This is obvious.
(ii) In CC Mode: implementing macros as islands would drastically
  simplify CC Mode.
(iii) In Shell-script mode: embedded "here documents" could be edited in
  their own mode (e.g. AWK Mode).
(iv) (Maybe) Line comments could be islands.  This might be a bit over
  the top.
(v) In putative LEX and YACC Modes.

POSSIBLE USE OF STREAMS:
(i) In literate programing.

What do people think (other than the obvious, that I should implement it
myself ;-)?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[David De La Harpe Golden]

On 22/11/10 19:38, Alan Mackenzie wrote:

> So have I, vaguely.  Here are my thoughts:
>
> Emacs's syntax and movement routines should be enhanced to handle
> "islands".  An @dfn{island} is a contiguous region of text where a
> major mode different from the surrounding text's is in force.  It might
> be feasible to mark an island with syntax-table text props, it might not.
> Islands can be nested.
>
> Movement commands normally don't recognise islands as anything unusual,
> and just move into/out of them.  By binding variable "respect-islands" to
> non-nil, any movement command would skip over any islands it encountered,
> and such commands could not move point out of an island.
>
> Several islands with the same major mode can by chained together as a
> @dfn{stream}.  When respect-islands is non-nil, movement commands can
> jump over the "ocean" to the next/previous island in the chain.
>
> Some other Emacs features, such as font locking, would need enhancement.
>
> POSSIBLE USES OF ISLANDS:
> (i) In mumamo.  This is obvious.
> (ii) In CC Mode: implementing macros as islands would drastically
>    simplify CC Mode.
> (iii) In Shell-script mode: embedded "here documents" could be edited in
>    their own mode (e.g. AWK Mode).
> (iv) (Maybe) Line comments could be islands.  This might be a bit over
>    the top.
> (v) In putative LEX and YACC Modes.
>
> POSSIBLE USE OF STREAMS:
> (i) In literate programing.
>
> What do people think (other than the obvious, that I should implement it
> myself ;-)?
>

in a way (a vague way) similar to what you're saying- wasn't there 
something about foliating with sortof hidden indirect buffers (rather 
mutant ones) last time this was discussed?  Making two indirect buffers 
to an underlying buffer and putting the indirect buffers in different 
modes already "nearly works" (though there are undoubtedly a lot of 
details that don't).  If the stretches "belonging" to the indirect 
buffer in mode X were sortof intangible stretches in the indirect buffer 
in mode Y and vice-versa, existing modes would need minimal adaptation 
(less than (IIRC) current mumamo's requirement for play-nice font 
locking everywhere).

(A below being the same type of mode as a, but nested in b, say a html 
string literal in javascript in html. Or something.)

aaabbbbbaaaabbbaabbbcccccbbAAAbbbbaaaaaaa [0] splitter
| |:   :|  |: :||:               :|     |
aaa_____aaaa___aa_________________aaaaaaa  [a from 0] mode ma
    :   :    : :  :               :
___bbbbb____bbb__bbbcccccbbAAAbbbb_______  [¬a from 0] splitter
    |   |    | |  | |:   :||: :|  |
___bbbbb____bbb__bbb_____bb___bbbb_______   [b from ¬a] mode mb
                     :   :  : :
____________________ccccc__AAA___________   [¬b from ¬a] splitter
                     |   |  : :
____________________ccccc________________    [c from ¬b] mode mc
                            : :
___________________________AAA___________    [A from ¬b] mode ma

:::::::::::::::::::::::::::::::::::::::::
aaabbbbaaaabbbaabbbccccccbbAAAbbbaaaaaaaa  Unifier (solid handwavium)

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Lennart Borgman]

On Tue, Nov 23, 2010 at 2:20 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 22/11/10 19:38, Alan Mackenzie wrote:
>
>> So have I, vaguely.  Here are my thoughts:
>>
>> Emacs's syntax and movement routines should be enhanced to handle
>> "islands".  An @dfn{island} is a contiguous region of text where a
>> major mode different from the surrounding text's is in force.  It might
>> be feasible to mark an island with syntax-table text props, it might not.
>> Islands can be nested.
>>
>> Movement commands normally don't recognise islands as anything unusual,
>> and just move into/out of them.  By binding variable "respect-islands" to
>> non-nil, any movement command would skip over any islands it encountered,
>> and such commands could not move point out of an island.
>>
>> Several islands with the same major mode can by chained together as a
>> @dfn{stream}.  When respect-islands is non-nil, movement commands can
>> jump over the "ocean" to the next/previous island in the chain.
>>
>> Some other Emacs features, such as font locking, would need enhancement.
>>
>> POSSIBLE USES OF ISLANDS:
>> (i) In mumamo.  This is obvious.
>> (ii) In CC Mode: implementing macros as islands would drastically
>>   simplify CC Mode.
>> (iii) In Shell-script mode: embedded "here documents" could be edited in
>>   their own mode (e.g. AWK Mode).
>> (iv) (Maybe) Line comments could be islands.  This might be a bit over
>>   the top.
>> (v) In putative LEX and YACC Modes.
>>
>> POSSIBLE USE OF STREAMS:
>> (i) In literate programing.
>>
>> What do people think (other than the obvious, that I should implement it
>> myself ;-)?
>>
>
> in a way (a vague way) similar to what you're saying- wasn't there something
> about foliating with sortof hidden indirect buffers (rather mutant ones)
> last time this was discussed?  Making two indirect buffers to an underlying
> buffer and putting the indirect buffers in different modes already "nearly
> works" (though there are undoubtedly a lot of details that don't).  If the
> stretches "belonging" to the indirect buffer in mode X were sortof
> intangible stretches in the indirect buffer in mode Y and vice-versa,
> existing modes would need minimal adaptation (less than (IIRC) current
> mumamo's requirement for play-nice font locking everywhere).

Maybe indirect buffers could be used too, but I am not sure it is
needed (for hiding portions of the buffer text).

However in the current (not released) version of mumamo.el I have
implemented "mirror buffers" (or tried to do it, it is not that easy)
that copies chunks with the same major modes to a new buffer and
leaves the rest of the buffer blank. This is not intended for long
time use - instead it is meant as a way to prove the concept and move
on to a better implementation (the one we are talking about here).

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Stefan Monnier]

> What do people think (other than the obvious, that I should implement it
> myself ;-)?

FWIW, I think it's worthwhile to look at multi-major-mode support in the
context of strings and comments.


        Stefan

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 22 Nov 2010 23:48:56 -0500
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,
> 	Lennart Borgman <lennart.borgman@gmail.com>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> > What do people think (other than the obvious, that I should implement it
> > myself ;-)?
> 
> FWIW, I think it's worthwhile to look at multi-major-mode support in the
> context of strings and comments.

Agreed.

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Lennart Borgman]

On Tue, Nov 23, 2010 at 5:48 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> What do people think (other than the obvious, that I should implement it
>> myself ;-)?
>
> FWIW, I think it's worthwhile to look at multi-major-mode support in the
> context of strings and comments.

Can you explain what you mean? Is it different in some way from
"normal" multi major mode support?

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Stefan Monnier]

>>> What do people think (other than the obvious, that I should implement it
>>> myself ;-)?
>> FWIW, I think it's worthwhile to look at multi-major-mode support in the
>> context of strings and comments.
> Can you explain what you mean?

That the content of strings and comment should be interpreted as being
in a different mode (e.g. text-mode).  From this point of view, *all*
programming languages need support for multiple major modes.


        Stefan

Re: Islands and streams

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Emacs's syntax and movement routines should be enhanced to handle
> "islands".  An @dfn{island} is a contiguous region of text where a
> major mode different from the surrounding text's is in force.  It might
> be feasible to mark an island with syntax-table text props, it might not.
> Islands can be nested.
>
> Movement commands normally don't recognise islands as anything unusual,
> and just move into/out of them.  By binding variable "respect-islands" to
> non-nil, any movement command would skip over any islands it encountered,
> and such commands could not move point out of an island.
>
> Several islands with the same major mode can by chained together as a
> @dfn{stream}.  When respect-islands is non-nil, movement commands can
> jump over the "ocean" to the next/previous island in the chain.
>
> Some other Emacs features, such as font locking, would need enhancement.

[...]

> What do people think (other than the obvious, that I should implement it
> myself ;-)?

That it is an excessively bad idea.  Lots of Elisp code relies on
(= (1+ (point)) (save-excursion (forward-char) (point)))
and similar equivalences.  For this reason, "intangible" regions have
never worked reliably, and only in very limited contexts.  Also for this
reason, multibyte support was quite unreliable and unpredictable until
buffer positions were made to correspond to character positions instead
of byte counts.

If you want something like this to work at all, all "wrong" parts of the
buffer must disappear completely from character counts and similar.
Then you need not worry about fixing syntax highlighting and similar.
It will just work.

Other than that, it will never work reliably.

-- 
David Kastrup

Re: Islands and streams

[Alan Mackenzie]

Evening, David!

On Tue, Nov 23, 2010 at 10:21:32AM +0100, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Emacs's syntax and movement routines should be enhanced to handle
> > "islands".  An @dfn{island} is a contiguous region of text where a
> > major mode different from the surrounding text's is in force.  It might
> > be feasible to mark an island with syntax-table text props, it might not.
> > Islands can be nested.

> > Movement commands normally don't recognise islands as anything unusual,
> > and just move into/out of them.  By binding variable "respect-islands" to
> > non-nil, any movement command would skip over any islands it encountered,
> > and such commands could not move point out of an island.

> > Several islands with the same major mode can by chained together as a
> > @dfn{stream}.  When respect-islands is non-nil, movement commands can
> > jump over the "ocean" to the next/previous island in the chain.

> > Some other Emacs features, such as font locking, would need enhancement.

> [...]

> > What do people think (other than the obvious, that I should implement it
> > myself ;-)?

> That it is an excessively bad idea.  Lots of Elisp code relies on
> (= (1+ (point)) (save-excursion (forward-char) (point)))
> and similar equivalences.  For this reason, "intangible" regions have
> never worked reliably, and only in very limited contexts.  Also for this
> reason, multibyte support was quite unreliable and unpredictable until
> buffer positions were made to correspond to character positions instead
> of byte counts.

That's a good point.  But by default, the new feature would not be
enabled.  Only when a major mode binds `respect-islands' would it come
into effect, and presumably the major mode would know what it was doing.

> If you want something like this to work at all, all "wrong" parts of the
> buffer must disappear completely from character counts and similar.
> Then you need not worry about fixing syntax highlighting and similar.
> It will just work.

You mean, throw out the absolutely standard buffer position integer?

> Other than that, it will never work reliably.

Thanks for the optimism!  ;-)

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Islands and streams

[Lennart Borgman]

On Tue, Nov 23, 2010 at 11:23 PM, Alan Mackenzie <acm@muc.de> wrote:
> Evening, David!
>
> On Tue, Nov 23, 2010 at 10:21:32AM +0100, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Emacs's syntax and movement routines should be enhanced to handle
>> > "islands".  An @dfn{island} is a contiguous region of text where a
>> > major mode different from the surrounding text's is in force.  It might
>> > be feasible to mark an island with syntax-table text props, it might not.
>> > Islands can be nested.
>
>> > Movement commands normally don't recognise islands as anything unusual,
>> > and just move into/out of them.  By binding variable "respect-islands" to
>> > non-nil, any movement command would skip over any islands it encountered,
>> > and such commands could not move point out of an island.
>
>> > Several islands with the same major mode can by chained together as a
>> > @dfn{stream}.  When respect-islands is non-nil, movement commands can
>> > jump over the "ocean" to the next/previous island in the chain.
>
>> > Some other Emacs features, such as font locking, would need enhancement.
>
>> [...]
>
>> > What do people think (other than the obvious, that I should implement it
>> > myself ;-)?
>
>> That it is an excessively bad idea.  Lots of Elisp code relies on
>> (= (1+ (point)) (save-excursion (forward-char) (point)))
>> and similar equivalences.  For this reason, "intangible" regions have
>> never worked reliably, and only in very limited contexts.  Also for this
>> reason, multibyte support was quite unreliable and unpredictable until
>> buffer positions were made to correspond to character positions instead
>> of byte counts.
>
> That's a good point.  But by default, the new feature would not be
> enabled.  Only when a major mode binds `respect-islands' would it come
> into effect, and presumably the major mode would know what it was doing.

Maybe I am misunderstanding something here. What I proposed was low
level changes that makes chunks in other major modes look like they
were just filled with spaces.

Is not this the same as you propose, Alan?
Is there any problems with such a change? (Other than implementing it. ;-)

Re: Islands and streams [Was: convert regex.c, .... to standard C]

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Movement commands normally don't recognise islands as anything
> unusual, and just move into/out of them.  By binding variable
> "respect-islands" to non-nil, any movement command would skip over any
> islands it encountered, and such commands could not move point out of
> an island.
>
> Several islands with the same major mode can by chained together as a
> @dfn{stream}.  When respect-islands is non-nil, movement commands can
> jump over the "ocean" to the next/previous island in the chain.

Sorry I'm late to the discussion, but the existing concept of fields
does something similar---it restricts certain motion and editing
commands.  Have you looked into the possibility of extending fields to
do what you describe?

Re: convert regex.c, strftime.c mktime.c to standard C

[Stefan Monnier]

> (And only the first `re-search-forward' would move the gap, since after
> moving it to before point, no further gap moves would be necessary.)

Actually, I think such a gap-move would still be necessary (tho only by
a single char) because when searching forward, the regexp code may have
to look at the char before point.


        Stefan

Re: convert regex.c, strftime.c mktime.c to standard C

[Richard Stallman]

    (while (re-search-forward "foo" nil t)
      (insert "bar"))

    or something, and the `re-search-forward' moved the gap to before point,
    it's not obvious (at least not to me :-) how big the performance hit
    would be, since the `insert' most likely moves the gap, anyway.

Moving the gap to point (or to point-1 so the previous char can be checked)
is probably not a disaster, just somewhat of a disadvantage.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org