[Top][All Lists]

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

bug#25055: 25.1.50; completion buffer changes window size

From: Tyler Smith
Subject: bug#25055: 25.1.50; completion buffer changes window size
Date: Wed, 19 Apr 2017 21:19:40 -0400

> On Sat, Apr 15, 2017, at 10:49 AM, martin rudalics wrote:
> > 
> > If for some reason you cannot build Emacs or work with master, please
> > tell me.  I'll then try to explain how to get the desired behavior with
> > Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
> > 

Sorry, I spoke too soon. I didn't use emacs -Q, and so forgot that I had
a work-around in my .emacs that hides the problem.

I can't currently compile the master branch. I checked out the latest
commit from github.  I had been using the emacs-25 branch previously,
and assumed the specific commands you suggested (recompile window.el et
al) would be taken care of by rebuilding the program completely.
However, `make` on its own complained:

make: *** No rule to make target 'lib/Makefile.am', needed by
'lib/Makefile.in'.  Stop.

So I ran 
./autogen.sh all

which failed with:

Loading macroexp.elc...
Wrong type argument: cl-slot-descriptor, [cl-struct-cl-slot-descriptor
parent-instance unbound eieio-instance-inheritor ((:documentation . "The
parent of this instance.
If a slot of this class is referenced, and is unbound, then the parent
is checked for a value."))]
Makefile:84: recipe for target
'../../lisp/cedet/semantic/bovine/c-by.el' failed
make[3]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Error 255
make[3]: Leaving directory
Makefile:358: recipe for target 'semantic' failed
make[2]: *** [semantic] Error 2
make[2]: Leaving directory
Makefile:734: recipe for target '../lisp/loaddefs.el' failed
make[1]: *** [../lisp/loaddefs.el] Error 2
make[1]: Leaving directory
Makefile:416: recipe for target 'src' failed
make: *** [src] Error 2

So I can't actually confirm that the bug is fixed or not. Assuming this
is just a transient issue in the master branch, I'm happy to wait and
try again later on. As I mentioned above I have a work-around that
smooths over this issue locally.



reply via email to

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