> ah is this why I've never been able to get completion working in
> LilyPond-mode?
Probably. Add this to your .emacs file:
(load-library "lilypond-mode")
(define-key LilyPond-mode-map [tab] 'LilyPond-autocompletion)
Werner
___
lilypond-
Working platforms: linux-x86, mingw, linux-ppc, linux-64,
freebsd-x86, darwin-x86, darwin-ppc.
Still failing: freebsd-64:
make[3]: Entering directory
`/home/lilydev/vc/gub3/target/freebsd-64/build/cross/binutils-2.18/gas/po'
make[3]: *** No rule to make target `info'. Stop.
make[3]: Leaving dir
On Tue, 17 Feb 2009 19:15:37 +0100 (CET)
Werner LEMBERG wrote:
>
> Keyword completion in lilypond-mode.el is by default assigned to
> . With my openSuSE 11.1 X11 setup, this key apparently
> doesn't exist in Emacs 22.3.1 by default; I've only TAB (which is
> translated from ).
>
> It's easy to
On Tue, Feb 17, 2009 at 1:55 PM, Patrick McCarty wrote:
>
> The log for x86 is identical to the previous one. However, this looks
> a bit suspicious:
>
>configure:2022: checking for none-apple-darwin8-strip
>configure:2051: result: no
>configure:2060: checking for strip
>configure
Hi Jan,
On Tue, Feb 17, 2009 at 02:51:55PM +0100, Jan Nieuwenhuizen wrote:
> On di, 2009-02-17 at 01:58 -0800, Patrick McCarty wrote:
>
> > With that workaround, I can now build LilyPond for all target
> > platforms except for darwin-x86. GUB fails at darwin-x86::gmp. See
> > the attached confi
Hi Jan,
On Tue, Feb 17, 2009 at 02:45:20PM +0100, Jan Nieuwenhuizen wrote:
>
> Okay. Below is my sys_lib_search_path_spec, notice the
> target/mingw/root/usr/lib bit. What does yours
> (target/mingw/root/usr/lib/libtool) look like?
Here it is (from target/mingw/root/usr/bin/libtool):
# Com
Keyword completion in lilypond-mode.el is by default assigned to
. With my openSuSE 11.1 X11 setup, this key apparently
doesn't exist in Emacs 22.3.1 by default; I've only TAB (which is
translated from ).
It's easy to redefine this with .emacs, but I wonder why
is used at all instead of plain .
Hi,
On Tue, 17 Feb 2009, Jonathan Kulp wrote:
> Graham Percival wrote:
>
> > 3. I'm not certain if git-clone sets up everything for doing
> > "git pull origin" and "git push origin".
>
> Yes, it does set things up properly. I first acquired the repo using
> the git-clone command and now I gr
Hi,
On Tue, 17 Feb 2009, Graham Percival wrote:
> On Mon, Feb 16, 2009 at 06:36:24PM -0700, Andrew Hawryluk wrote:
> > In the instructions for getting the source code, why not just use
> > git-clone? Is there a difference? The currently suggested method of
> > remote-add + checkout produces a bun
Graham Percival wrote:
3. I'm not certain if git-clone sets up everything for doing
"git pull origin" and "git push origin".
Yes, it does set things up properly. I first acquired the repo using
the git-clone command and now I grab updates just fine with git pull
origin. I think these are
> Hidoi! Boku wa oyaji desu? Boku wa tada san-juu-sai! :(
Soo desu ne!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Tue, Feb 17, 2009 at 08:54:44AM +, Sawada, Yoshiki wrote:
> Hello "nice" Graham,
>
> Graham Percival percival-music.ca> writes:
> > > "nice" is not needed, that's a Grahamism,
> >
> > Yes, I'm a very "nice" person. ;)
>
> The humor like yours may be called "Oyaji Gyagu" in Japan :-)
Hi
On Mon, Feb 16, 2009 at 06:36:24PM -0700, Andrew Hawryluk wrote:
> In the instructions for getting the source code, why not just use
> git-clone? Is there a difference? The currently suggested method of
> remote-add + checkout produces a bunch of warnings (below).
1. git-clone gets the entire rep
On Tue, Feb 17, 2009 at 10:51 AM, Jan Nieuwenhuizen
wrote:
>> With that workaround, I can now build LilyPond for all target
>> platforms except for darwin-x86. GUB fails at darwin-x86::gmp. See
>> the attached config.log.
>
> Okay, this is prolly what Han-Wen was talking about, a linux-x86
> on
On di, 2009-02-17 at 01:58 -0800, Patrick McCarty wrote:
Hi Patrick,
> I managed to find a temporary workaround by adding
> $HOME/git/gub/target/mingw/root/usr/lib to my PATH. Then libtool
> found the .la files (and the .a file in the case of ws2_32), and
> mingw::guile built successfully.
Grea
On ma, 2009-02-16 at 16:39 -0800, Patrick McCarty wrote:
Hi Patrick,
> Using LIBRESTRICT=open:stat no longer breaks the build for me. But
> the output of build.log does not seem to provide any useful
> information, besides `dash' being used instead of `sh'.
Great. I don't understand it does no
Mark
I long last I got around to adding this (and the examples
in your earlier note) to the LSR! It still needs approval,
though - it this OK, Valentin?
Many thanks.
Trevor
- Original Message -
From: "Mark Polesky"
To:
Sent: Wednesday, September 10, 2008 2:16 PM
Subject: Re: docum
Hi Jan,
On Mon, Feb 16, 2009 at 11:19:32AM +0100, Jan Nieuwenhuizen wrote:
> iOn zo, 2009-02-15 at 19:13 -0800, Patrick McCarty wrote:
>
> > Those files exist, and libintl.la looks correct. It is not executable
> > (755) like all of the other .la files I see, but this does not seem to
> > make a
Hello "nice" Graham,
Graham Percival percival-music.ca> writes:
> > "nice" is not needed, that's a Grahamism,
>
> Yes, I'm a very "nice" person. ;)
The humor like yours may be called "Oyaji Gyagu" in Japan :-)
> Basically, it came down to this: if somebody doesn't know what
> they're doing, t
Hello John,
John Mandereau gmail.com> wrote:
> > It does not work. But I fixed Lilypond-book.py as following:
> > (line 939)
> > if not langdefs.LANGDICT[document_language].enable_ly_identifier_l10n:
> >^^^
> > I guess the property name "enable_ly_identifier_l10n" should be changed
20 matches
Mail list logo