bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Emacs 21.3.1: build ?bug?, regex weirdness, batch ?bug?


From: Bernard Leak
Subject: GNU Emacs 21.3.1: build ?bug?, regex weirdness, batch ?bug?
Date: Wed, 30 Apr 2003 00:59:01 +0100
User-agent: KMail/1.4.3

Dear Whoever,
                          I've been having a few small problems with my
own fresh build of GNU Emacs 21.3.1.  Just to confuse, there
are several things going on which seem to be wholly independent.

The build calls itself
GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit) of 2003-04-26 on 
localhost.localdomain

This was a very squeaky-clean build on a spanking new P4 
AT-compatible running Mandrake [GNU/[XFree86/[add bits to suit/]]]Linux 9.0
(*very* recently installed and still pretty clean).

Unpack emacs-21.3.tar.gz
Unpack leim-21.3.tar.gz
(patch an irrelevant file - I add my own indentation
 style to lisp/progmodes/cc-styles.el)

./configure
make [installation directory options]
make install [installation directory options]

[First problem:]
This *looks* like a bug; I shall investigate it in more detail
(unless I hear something definitive from you first).

I've been trying to make the new build slip in next to the
version installed by the distribution, for various reasons that
needn't occupy your time.
This is the first time that I've forced the installation directory
while building GNU Emacs (and the first time I've built
GNU Emacs 21.3, as well).

make datadir=<whatever> bindir=<whatever2>
make install datadir=<whatever> bindir=<whatever2>

puts the files where instructed, but the build itself
seems to ignore the datadir=<whatever> argument,
so the locations don't match.
Maybe bindir=<whatever> is also ignored except
during installation, but the build doesn't care.

[Second problem]
This is either an implementation failure or
a specification failure, surely?

I wanted to produce a string which would test
for old versions of the Emacs regex parser, from
before it became more Perl-ified (version 20?):
I tried (just for the hell of it)
M-x     query-replace-regex<RET>
\(?:\)<RET>bong<RET>!
with the mark just before

123<LF>
4<LF>
5<EOF>

This produced
bong1bong2bong3bong<LF>
bong4bong<LF>
bong5<EOF>

This seems to be doing something which
can't be expressed easily (officially, at least):
it is *matching* a single character (apparently
*any* character, but I haven't checked this)
but *replacing* the empty string which it was
meant to match, leaving the mark one position
later than expected.  
        
\(?:?\) and \(?:*\)
match as (possibly) expected - that is, they match
'?' and '*' characters (a horrid case of backward
compatibility).  That is, they behave just like
? and * 

I find also that
\{<whatever>\}
never seems to match when it has
no back-referred expression, but
is not complained about.  Is this a
bug, a feature, or what?

Looking a bit further...
1\(?\)3
is an "invalid regular expression"
(really?  Shouldn't the backward-compatibility
stuff make it equivalent to the following line?)
1\?3
but
1\(*\)3
is not (and matches the following line).
1*3

On the other hand,
1\(?:?\)3
is not complained of, but does *not* match
1?3
while
1\(?:*\)3
is not complained of either, but *does* match
1*3

None of these cases shows the strange "does it match
or doesn't it?" behaviour of 
\(?:?\)
but the decisions about what is invalid and what
never matches seem wildly inconsistent, while
\(?:?\)
merely behaves weirdly.

Who needs Zippy the Pinhead when you can have
Emacs regular expressions?

[Third problem]
Slap this into a file and byte-compile the file:

(defun thingy
 (set-buffer (get-create-buffer "*spong*"))
 (end-of-buffer)
)

Now invoke it from the minibuffer:
M-:(thingy)<RET>
and it works.
You can also add in an (interactive) if you like
and invoke it with M-xthingy<RET>
No problem.
Now try it from a batch file:
emacs-21.3 --batch --load temp.elc --funcall thingy
*boom!* A seggy...

Rewriting it a bit more cleanly, replacing
(end-of-buffer)
with
(goto-char (point-max))
makes it work in batch mode.
But, leaving aside the effect on the mark,
why did the original melt?
Running it through gdb leaves *me* none the wiser,
though you may be able to do better: I give you a
quick drag up through the call chain from the point
of failure:

Program received signal SIGSEGV, Segmentation fault.
0x0805da55 in start_display (it=0xbfffe920, w=0x8297120, pos=
      {charpos = 1, bytepos = -1073747760}) at xdisp.c:1717
1717      row = w->desired_matrix->rows + first_vpos;

(gdb) print w
$1 = (struct window *) 0x8297120
(gdb) print w->desired_matrix
$2 = (struct glyph_matrix *) 0x0

Well, that's understandable, but...
now chase up the stack:

(gdb) up
#1  0x182b0fbc in ?? ()
(gdb) up
#2  0x080780cb in Fwindow_end (window=405271260, update=405271308)
    at window.c:935
935           start_display (&it, w, startp);
(gdb) up
#3  0x0813077b in Ffuncall (nargs=3, args=0xbfffeb98) at eval.c:2659
2659              val = (*XSUBR (fun)->function) (internal_args[0]);
(gdb) up
#4  0x08159b72 in Fbyte_code (bytestr=1, vector=2, maxdepth=-1073747052)
    at bytecode.c:716
716                 TOP = Ffuncall (op + 1, &TOP);
(gdb) up
#5  0x08130ac7 in funcall_lambda (fun=1209762804, nargs=0, 
    arg_vector=0xbfffeca4) at eval.c:2851
2851          val = Fbyte_code (XVECTOR (fun)->contents[COMPILED_BYTECODE],
(gdb) up
#6  0x08130692 in Ffuncall (nargs=1, args=0xbfffeca0) at eval.c:2716
2716            val = funcall_lambda (fun, numargs, args + 1);
(gdb) up
#7  0x08159b72 in Fbyte_code (bytestr=138602172, vector=0, 
    maxdepth=-1073746784) at bytecode.c:716
716                 TOP = Ffuncall (op + 1, &TOP);
(gdb) up
#8  0x08130ac7 in funcall_lambda (fun=1212637600, nargs=0, 
    arg_vector=0xbfffedb4) at eval.c:2851
2851          val = Fbyte_code (XVECTOR (fun)->contents[COMPILED_BYTECODE],
(gdb) up
#9  0x08130692 in Ffuncall (nargs=1, args=0xbfffedb0) at eval.c:2716
2716            val = funcall_lambda (fun, numargs, args + 1);
(gdb) up
#10 0x08159b72 in Fbyte_code (bytestr=138664100, vector=0, 
    maxdepth=-1073746512) at bytecode.c:716
716                 TOP = Ffuncall (op + 1, &TOP);
(gdb) up
#11 0x08130ac7 in funcall_lambda (fun=1210223828, nargs=1, 
    arg_vector=0xbfffeee4) at eval.c:2851
2851          val = Fbyte_code (XVECTOR (fun)->contents[COMPILED_BYTECODE],
(gdb) up
#12 0x08130692 in Ffuncall (nargs=2, args=0xbfffeee0) at eval.c:2716
2716            val = funcall_lambda (fun, numargs, args + 1);
(gdb) up
#13 0x08159b72 in Fbyte_code (bytestr=2, vector=1, maxdepth=-1073746208)
    at bytecode.c:716
716                 TOP = Ffuncall (op + 1, &TOP);
(gdb) up
#14 0x08130ac7 in funcall_lambda (fun=1210214444, nargs=0, 
    arg_vector=0xbffff004) at eval.c:2851
2851          val = Fbyte_code (XVECTOR (fun)->contents[COMPILED_BYTECODE],
(gdb) up
#15 0x08130692 in Ffuncall (nargs=1, args=0xbffff000) at eval.c:2716
2716            val = funcall_lambda (fun, numargs, args + 1);
(gdb) up
#16 0x08159b72 in Fbyte_code (bytestr=136974236, vector=0, 
    maxdepth=-1073745920) at bytecode.c:716
716                 TOP = Ffuncall (op + 1, &TOP);
(gdb) up
#17 0x08130ac7 in funcall_lambda (fun=1210210508, nargs=0, 
    arg_vector=0xbffff0c0) at eval.c:2851
2851          val = Fbyte_code (XVECTOR (fun)->contents[COMPILED_BYTECODE],
(gdb) up
#18 0x08130974 in apply_lambda (fun=1210210508, args=405271260, eval_flag=1)
    at eval.c:2770
2770      tem = funcall_lambda (fun, XINT (numargs), arg_vector);
(gdb) up
#19 0x0812fb68 in Feval (form=405271260) at eval.c:2071
2071            val = apply_lambda (fun, original_args, 1);
(gdb) up
#20 0x080d6fe2 in top_level_2 () at keyboard.c:1254
1254      return Feval (Vtop_level);
(gdb) up
#21 0x0812eb1a in internal_condition_case (bfun=0x80d6fd0 <top_level_2>, 
    handlers=405367604, hfun=0x80d6d00 <cmd_error>) at eval.c:1267
1267      val = (*bfun) ();
(gdb) up
#22 0x080d7018 in top_level_1 () at keyboard.c:1262
1262        internal_condition_case (top_level_2, Qerror, cmd_error);
(gdb) up
#23 0x0812e6b2 in internal_catch (tag=0, func=0x80d6ff0 <top_level_1>, 
    arg=405271260) at eval.c:1030
1030        c.val = (*func) (arg);
(gdb) up
#24 0x080d6f59 in command_loop () at keyboard.c:1223
1223            internal_catch (Qtop_level, top_level_1, Qnil);
(gdb) up
#25 0x080d6a9a in recursive_edit_1 () at keyboard.c:950
950       val = command_loop ();
(gdb) up
#26 0x080d6bc9 in Frecursive_edit () at keyboard.c:1006
1006      recursive_edit_1 ();
(gdb) up
#27 0x080d557c in main (argc=6, argv=0xbffff734, envp=0xbffff750)
    at emacs.c:1547
1547      Frecursive_edit ();
(gdb) up
#28 0x40316082 in __libc_start_main () from /lib/i686/libc.so.6

                                                        Yours in puzzlement,

                                                                                
Bernard Leak.


P.S.  On an utterly different note...
I've patched calc-2.02f, the multiprecision calculator add-on for
GNU Emacs, to work more cleanly with frames and to not get
confused by minibuffer prompt strings.  These had obviously
been suppressed in older versions of GNU Emacs (I think I
had the code working with Emacs 19.something), but then
in Emacs 20.something the prompt was returned as part of
the buffer contents.  Now we have
(minibuffer-contents-no-properties)
and (minibuffer-prompt-end), or the equivalent in terms
of (field-beginning) and (field-string-no-properties), so I've
patched the necessary places accordingly.

Dave Gillespie, the original and Onlie Begetter, is universally
listed as the contact man, but I've had no joy trying to get in
touch with him.  Does anyone know whether anyone is now
looking after this code?

PPS:  Looking at simple.el, I find that the documentation
strings for
(defun minibuffer-contents ()
and
(defun minibuffer-contents-no-properties ()
both have "minbuffer" for "minibuffer".

                                                                Bernard (still 
me) Leak.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]