Patchy email

[patchy]

09:24:04 (UTC) Begin LilyPond compile, previous commit at   
309687117b7a10b20cd958147174a906e308ccb6
09:24:16 Merged staging, now at:309687117b7a10b20cd958147174a906e308ccb6
09:24:18Success:./autogen.sh --noconfigure
09:24:43Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
09:24:48Success:nice make clean
09:30:08Success:nice make -j3
09:39:37Success:nice make test -j3
09:54:56 *** FAILED BUILD ***
nice make doc -j3
Previous good commit:   188c8e6d80df96e4ef7040e0df5b7b1520260d36
Current broken commit:  309687117b7a10b20cd958147174a906e308ccb6
09:54:56 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j3
See the log file log-staging-nice-make-doc--j3.txt
09:54:57 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
523, in handle_staging
self.build (issue_id=issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
328, in build
issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, 
this_logfilename))
FailedCommand: Failed runner: nice make doc -j3
See the log file log-staging-nice-make-doc--j3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

[David Kastrup]

pat...@gnu.org writes:

> 09:24:04 (UTC) Begin LilyPond compile, previous commit at 
> 309687117b7a10b20cd958147174a906e308ccb6
> 09:24:16 Merged staging, now at:  309687117b7a10b20cd958147174a906e308ccb6
> 09:24:18  Success:./autogen.sh --noconfigure
> 09:24:43  Success:/tmp/lilypond-autobuild/configure 
> --disable-optimising
> 09:24:48  Success:nice make clean
> 09:30:08  Success:nice make -j3
> 09:39:37  Success:nice make test -j3
> 09:54:56 *** FAILED BUILD ***
>   nice make doc -j3
>   Previous good commit:   188c8e6d80df96e4ef7040e0df5b7b1520260d36
>   Current broken commit:  309687117b7a10b20cd958147174a906e308ccb6
> 09:54:56 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make doc -j3
> See the log file log-staging-nice-make-doc--j3.txt
> 09:54:57 Traceback (most recent call last):
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 523, in handle_staging
> self.build (issue_id=issue_id)
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 328, in build
> issue_id)
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, 
> this_logfilename))
> FailedCommand: Failed runner: nice make doc -j3
> See the log file log-staging-nice-make-doc--j3.txt

That one's mine, actually.  GhostScript has thrown segfaults because of
buffer overruns here, and what I pushed is not actually related to
PostScript production.  I tend to assign the fault to just having
upgraded my version of Ubuntu and probably getting hit by a bad library.
If someone else could check...

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Busy Developer's Summary 8: correct pdf display, academic papers, new contributor

[Janek Warchoł]

A bit late, but here it is:

- a lot of work is being done on correct rendering of Stems and other
objects in pdf output.  This was a longstanding issue, but i think
there's a fair chance of the fix being available in 2.18:
http://code.google.com/p/lilypond/issues/detail?id=2658
https://codereview.appspot.com/8663044

- Urs Liska writes a 'lobbying' paper about using plain text for music
editing.  This could have a big influence in some circles.  He's also
having a presentation about this on his University.
http://lists.gnu.org/archive/html/lilypond-user/2013-04/msg00562.html

- we're still discussing how to make Mike's skyline changes as
"backwards-compatible" as possible.
https://codereview.appspot.com/8613043/

- Aleksandr Andreev is offering a bounty for fixing Kievan issues:
http://lists.gnu.org/archive/html/lilypond-devel/2013-04/msg00315.html
($100 for each)

- Fan Ziye, a new contributor, posted his first patch:
http://code.google.com/p/lilypond/issues/detail?id=1367
https://codereview.appspot.com/8593046
let's review it!

hth,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Point and Click does not work on Windows

[ArnoldTheresius]

Eluze wrote
> 
> ArnoldTheresius wrote
>> 
>> Eluze wrote
>>> ...
>>> maybe my hope to find the needed information in thess tables was to
>>> optimistic - does somebody know how the "correct" way is?
>>> 
>>> Eluze
>> Well, at least here is what I did try this weekend - posted before I read
>> all messeages which were added in the meantime.
>> This code is still "dirty but quick, incomplete but big" 

>> Editors 'context' and 'pspad' are still missing.
>> Hopefully still good enough for some testing.
> hi Arnold
> 
> looks great! (but sorry - I can't test)
> 
> ...
>> Also to clearify:
>> - Which of the listed editors are available for windows?
> Crimson
> gvim
> notepad
> notepad++
> pspad
> …???
> 
> I think we should maintain a table where you can read the line and column
> option.
>> - Which one needs to be started into the background (like lilypad)?
> what do you mean exactly? (I can start: lilypad "d:\data\ly\test\test.ly"
> 
> after finding a viable way textedit and it's prerequisites should be
> documented clearer (in AU).
> 
> Eluze

*Well, let's to back to the roots.*

There is the *problem* "after installation of Lilypond point-and-click does
not work out of the box". (without installation of an 'integrated
development environment', e.g. frescobaldi)
I categorize this as 'bug'.
I *located* the problems to the windows installer and the file
lilypond-invoke-editor in the bin directory of the windows installation.
Suggested *solution* is: changes in the installation script and in
lilypond-invoke-editor
Result to obtain: Opens lilypad by point-and-click out of a pdf-viewer, e.g.
Acrobat reader.
  If the environment variable LYEDITOR (or XEDITOR or EDITOR) is defined
(supported values: emacs, gvim, uedit32, jedit ...),
  then this editor will be launched instead of lilypond.
  For testing you can enter the textedit command in the command interpreter
(DOS shell), e.g. »C:\...\usr\bin\guile.exe -s
C:\...\usr\bin\lilypond-invoke-editor
textedit://C:/MyLilypondWorkDir/testfile.ly:17:9:9«
Unchanged standard behavior: If the editor is not in the search path for
command line usage, you still have to qualify the complete call with all
options in the environment variable.
  


Next *Problem*: "each time I click in the pdf a new tab is opened in my
browser!" (Eluze, 2012-04-11, bugs/point and click implementation)
Also testable: the commandline execution listed above does not return until
lilypad is closed.
I categorize this as 'usability or bug'.
Related *Problem*: support additional editors (on windows)
I categorize this as 'enhancement'.
I *located*: in file scm/editor.scm is an assiciation list
'editor-command-template-alist'.
Suggested *solution* is:
  Expand the association list 'editor-command-template-alist'
  On (eq? PLATFORM 'windows) use »start lilypad ...«
Result to obtain:
  new editors 'context', 'notepad++' and 'pspad' available (by specification
in env. var. LYEDITOR)
  launch of lilypad does no longer create an empty tab in the browser, and
executing the textedit command line in the command interpreter (DOS Shell)
does no longer wait for lilypad.
*Still to examine*:
  Do other editor commands require the »start« prefix in windows? (most
simple: command line check)
  I just tested 'gvim': no start prefix required.



Next *Problem*: "FIXME: how aore default/preferred editors specified on
different paltforms?" (from scm/editor.scm)
  Try this for windows by reading from the windows registry.
/Clearification in progress/:
  Which the listed editors are available for windows:
According to wikipedia these are: emacs, gvim, uedit32, gedit, jedit,
syn, context, notepad++, pspad, and of course lilypad,
  while not availabe for windows is nedit.


*TODO:*
Who has emacs, uedit32, gedit, jedit, syn, context, notepad++ and/or pspad
installed on his windows computer?
  Then correct the script lilypond-invoke-editor (see my mail form
2012-04-16), and make the command line check.
  Does it open the editor, and will the command prompt be back immediately
or only after closing the editor window.

Are there other important methods known how to select the default editor in
windows, and who they store this information (in the windows registry)?

Who will (and can off course) initiate the modification to the installer and
the lilypond-invoke-editor script?


*And some more information I found:*

On https://github.com/janneke/gub/blob/master/nsis/lilypond-prepost.nsh I
found in line 83:
  WriteRegExpandStr HKCR "textedit\shell\open\command" ""
'"$INSTDIR\usr\bin\guile.exe" -e main -s
"$INSTDIR\usr\bin\lilypond-invoke-editor.scm" "%1"'
Is this the installation script template used by the windows installer? Who
may change it to
  WriteRegExpandStr HKCR "textedit\shell\open\command" ""
'"$INSTDIR\usr\bin\guile.exe" -s "$INSTDIR\usr\bin\lilypond-invoke-editor"
"%1"'
and make it take effect on the next unstable build?

In the same file you find the registry definitons
  ...\Lilypond\shell\edit\comman

Re: Patchy email

[James]

Hello.


On 23 April 2013 11:18, David Kastrup  wrote:

> pat...@gnu.org writes:
>
> > 09:24:04 (UTC) Begin LilyPond compile, previous commit at
> 309687117b7a10b20cd958147174a906e308ccb6
> > 09:24:16 Merged staging, now at:
>  309687117b7a10b20cd958147174a906e308ccb6
> > 09:24:18  Success:./autogen.sh --noconfigure
> > 09:24:43  Success:/tmp/lilypond-autobuild/configure
> --disable-optimising
> > 09:24:48  Success:nice make clean
> > 09:30:08  Success:nice make -j3
> > 09:39:37  Success:nice make test -j3
> > 09:54:56 *** FAILED BUILD ***
> >   nice make doc -j3
> >   Previous good commit:   188c8e6d80df96e4ef7040e0df5b7b1520260d36
> >   Current broken commit:  309687117b7a10b20cd958147174a906e308ccb6
> > 09:54:56 *** FAILED STEP ***
> >   merge from staging
> >   Failed runner: nice make doc -j3
> > See the log file log-staging-nice-make-doc--j3.txt
> > 09:54:57 Traceback (most recent call last):
> >   File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 523, in handle_staging
> > self.build (issue_id=issue_id)
> >   File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 328, in build
> > issue_id)
> >   File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> > raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
> (command, this_logfilename))
> > FailedCommand: Failed runner: nice make doc -j3
> > See the log file log-staging-nice-make-doc--j3.txt
>
> That one's mine, actually.  GhostScript has thrown segfaults because of
> buffer overruns here, and what I pushed is not actually related to
> PostScript production.  I tend to assign the fault to just having
> upgraded my version of Ubuntu and probably getting hit by a bad library.
> If someone else could check...
>
>
Hmm..

Seems I turned off my patchy scripts for some maintenance and forgot to
re-enable them.

Sorry. They are back on now. Wait for 25 minutes to see if it merges.

Else I'll let you know

James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Point and Click does not work on Windows

[David Kastrup]

ArnoldTheresius  writes:

> Eluze wrote
>> 
>>> - Which one needs to be started into the background (like lilypad)?
>> what do you mean exactly? (I can start: lilypad "d:\data\ly\test\test.ly"
>> 
>> after finding a viable way textedit and it's prerequisites should be
>> documented clearer (in AU).
>> 
>
> *Well, let's to back to the roots.*
>
> There is the *problem* "after installation of Lilypond point-and-click does
> not work out of the box". (without installation of an 'integrated
> development environment', e.g. frescobaldi)
> I categorize this as 'bug'.
> I *located* the problems to the windows installer and the file
> lilypond-invoke-editor in the bin directory of the windows installation.
> Suggested *solution* is: changes in the installation script and in
> lilypond-invoke-editor

[...]

> Next *Problem*: "each time I click in the pdf a new tab is opened in my
> browser!" (Eluze, 2012-04-11, bugs/point and click implementation)
> Also testable: the commandline execution listed above does not return until
> lilypad is closed.
> I categorize this as 'usability or bug'.
> Related *Problem*: support additional editors (on windows)
> I categorize this as 'enhancement'.
> I *located*: in file scm/editor.scm is an assiciation list
> 'editor-command-template-alist'.
> Suggested *solution* is:

[...]

Welcome to LilyPond.  The classic mystery story revolves around the
question "Who dunnit?".  In contrast, our mystery stories tend to
revolve around the question "Who's gonna do it?".  Or even more of a
mystery, "How did anything ever get done?".

> *TODO:*
> Who has emacs, uedit32, gedit, jedit, syn, context, notepad++ and/or pspad
> installed on his windows computer?
>   Then correct the script lilypond-invoke-editor (see my mail form
> 2012-04-16), and make the command line check.
>   Does it open the editor, and will the command prompt be back immediately
> or only after closing the editor window.

This sort of task has two basic approaches:

a) do everything yourself

b) do whatever you feel is enough, then wait for users to complain about
   the rest

Approach b) has the slight disadvantage that "users" tend to take the
status quo for granted, will design the craziest of workarounds and
workflows, and tell everybody _else_ about them rather than reporting
back, giving you ulcers whenever you happen to chance upon such wisdom
when least expecting it.

Given the thoroughness you invested into thinking about this issue so
far, it's a safe bet that the least aggravating way to proceed is to
take care of it yourself as far as possible.  With regard to the
LilyPond installer, it may well be that you are leaving the core of your
expertise, so it might make sense to ask around for support with that.
But even though we manage to produce working binaries, a lot is due to
procedures once established and still working that are exercised not by
their original authors.

So it's important to distinguish between the kind of support for your
work that you'd like to see, and the kind of support that will make or
break what you are trying to accomplish.

> Are there other important methods known how to select the default
> editor in windows, and who they store this information (in the windows
> registry)?
>
> Who will (and can off course) initiate the modification to the
> installer and the lilypond-invoke-editor script?

The latter question seems of the make-or-break variety, indeed.

> *And finally:*
> I'll have a closer look to the documentation when the modifications for
> scm/editor.scm will be more clear.
> The global default (for all operating systems) seems to be:
> - Lilypond tries to evalute which editor you want to use - but the success
> will ever be limited, therfore

lilypond-invoke-editor, more likely, tries to evaluate this.

> - you can define the environment variable LYEDITOR to select the editor to
> use.
> - Set LYEDITOR to the short name of one of the predefined invoke editor
> syntax (e.g. emacs, gvim, lilypad - effectively listed in file
> scm/editor.scm) if this editor can be found by command line usage, i.e. its
> path is included in the search path.
> - Otherwise set LYEDITOR to qualify the full path name AND all additional
> options for the textedit launch.

That seems about right.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: is changing OctavateEight to ClefModifier appropriate for 2.18?

[Janek Warchoł]

hmm.  i don't see any protests so i'll push it.

2013/4/21 Janek Warchoł :
> 2013/4/21 David Kastrup :
>> Janek Warchoł  writes:
>>
>>> http://code.google.com/p/lilypond/issues/detail?id=3309
>>> https://codereview.appspot.com/8614045
>>>
>>> This had passed countdown (with 0 reviews). I'm not sure if it's
>>> "stable enough" to be included in 2.18 - should i push it or set it's
>>> status to waiting?
>>
>> I haven't reviewed the patch as such.  If it is just a rename, you
>> should be able to verify using "git grep" that no occurences of the old
>> name remain so I don't see that as a problematic change.
>
> I did that.  What worries me is that i've done this before, and
> apparently i missed some occurences then.  The rename seems not to be
> so trivial, that's why i'm not sure.  I'd feel more comfortable
> pushing this if there was any review.
>
> Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add the command \offset to LilyPond (issue 8647044)

[janek . lilypond]

anyway, this patch LTGM.

https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Document the use of \temporary (2938) (issue 8859044)

[janek . lilypond]

generally LGTM.


https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):

https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely#newcode413
Documentation/extending/programming-interface.itely:413: will then pop
the previous value.
Shouldn't this be "pop the new value" or "pop the temporarily overridden
value"?

https://codereview.appspot.com/8859044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: expand explanation of negative measurePosition (3080) (issue 8538050)

[janek . lilypond]

LGTM

https://codereview.appspot.com/8538050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Change \on-the-fly #procedure to \on-the-fly \procedure (3098) (issue 8853044)

[janek . lilypond]

LGTM

https://codereview.appspot.com/8853044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Doc: Remove space before the tie symbol (3133) (issue 8758047)

[janek . lilypond]

LGTM

https://codereview.appspot.com/8758047/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Document the use of \temporary (2938) (issue 8859044)

[dak]

https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):

https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely#newcode413
Documentation/extending/programming-interface.itely:413: will then pop
the previous value.
On 2013/04/23 13:19:05, janek wrote:

Shouldn't this be "pop the new value" or "pop the temporarily

overridden value"?

Indeed.  It is probably not overly helpful speaking of popping values
since that is ambiguous between "getting them" and "discarding them".
What is popped is actually the stack itself.  If we want to avoid too
much programmer lingo, we probably would rather write something like

"The use of @code{\temporary} causes the (usually set) @code{pop-first}
property in the override to be cleared, so the previous value is not
popped off the property stack before pushing the new value onto it.
When a subsequent @code{\revert} pops off the temporarily overriden
value, the previous value will reemerge."

https://codereview.appspot.com/8859044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Augment description of how to customise staff line positions (3175) (issue 8540046)

[janek . lilypond]

LGTM

https://codereview.appspot.com/8540046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Point and Click does not work on Windows

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, April 23, 2013 1:08 PM
Subject: Re: Point and Click does not work on Windows



ArnoldTheresius  writes:

Who will (and can off course) initiate the modification to the
installer and the lilypond-invoke-editor script?


The latter question seems of the make-or-break variety, indeed.


The strict answer is "anyone with push access to Graham's github account". 
That includes me and Julien and probably others.  To modify the installer 
requires NSIS experience.  I've essentially none of that, although I think I 
was the last person to mess with it.  If either Arnold or Eluze can create a 
patch, I'd be happy to test it once my rush of college work is over (end of 
May).


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[Janek Warchoł]

ooops, seems like i'd fallen behind.  The last thing i remembered
about \tweak syntax was this:
http://code.google.com/p/lilypond/issues/detail?id=2540
Back then the syntax was
\tweak optional-grobname property value music
And i liked it.  Somehow i didn't realize that this was changed into
\tweak property value grob-or-music
...

2013/4/22 David Kastrup :
> This was issue 2929
> http://code.google.com/p/lilypond/issues/detail?id=2929> and I
> answered your question in comment #7 in October.  The only alternative
> is to provide _only_ overrides and force the user to use \single if he
> needs a tweak.  But this requires the user to know the grob name for the
> override, defeating the simplicity of \tweak.

...yeah, that's it.  I didn't realize/understand it back then.

Btw, issue 2540 made it possible to write

\version "2.17.3"
{ < \tweak Accidental #'color #red cis' fis'' > }

which colored the sharp of the cis.  Is it possible to achieve the
same goal with newer versions?  I've tried some combinations with
2.17.13 but they failed.

> Janek Warchoł  writes:
>> It's not doing us good when user interfaces for different
>> functions don't have a common specification wrt/ argument
>> order.
>
> Where do we have different argument order to existing functions?

Uh, what about
\override grob property = value
\tweak property value grob-or-music
?
"grob" appears in different places - sometimes before a property name
and sometimes after it.  This is confusing.
I know that i don't know what to do about this, but i also know that i
don't quite like current situation.

>> (as you know, my ultimate goal is merging as many modifying
>> commands, e.g. merging \set and \override - but i'm not trying
>> to suggest any solutions, because i have no expertise in this
>> area, just some expectations).
>
> I don't see a better solution here.  Obviously, or I would not have
> converged to the behavior implemented in October.  Unless you can come
> up with anything that has not already been considered and/or discussed,
> this is not going to lead anywhere.

well, i have one idea that i think wasn't quite discussed.  However, i
suppose i have to learn more about parser and related things to have a
meaningful discussion, so i suppose this has to wait.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[David Kastrup]

Janek Warchoł  writes:

> ooops, seems like i'd fallen behind.  The last thing i remembered
> about \tweak syntax was this:
> http://code.google.com/p/lilypond/issues/detail?id=2540
> Back then the syntax was
> \tweak optional-grobname property value music
> And i liked it.  Somehow i didn't realize that this was changed into
> \tweak property value grob-or-music
> ...
>
> 2013/4/22 David Kastrup :
>> This was issue 2929
>> http://code.google.com/p/lilypond/issues/detail?id=2929> and I
>> answered your question in comment #7 in October.  The only alternative
>> is to provide _only_ overrides and force the user to use \single if he
>> needs a tweak.  But this requires the user to know the grob name for the
>> override, defeating the simplicity of \tweak.
>
> ...yeah, that's it.  I didn't realize/understand it back then.
>
> Btw, issue 2540 made it possible to write
>
> \version "2.17.3"
> { < \tweak Accidental #'color #red cis' fis'' > }
>
> which colored the sharp of the cis.  Is it possible to achieve the
> same goal with newer versions?  I've tried some combinations with
> 2.17.13 but they failed.

If you don't want to read the manual, you can use convert-ly.

>> Janek Warchoł  writes:
>>> It's not doing us good when user interfaces for different
>>> functions don't have a common specification wrt/ argument
>>> order.
>>
>> Where do we have different argument order to existing functions?
>
> Uh, what about
> \override grob property = value
> \tweak property value grob-or-music
> ?
> "grob" appears in different places - sometimes before a property name
> and sometimes after it.  This is confusing.

Then don't use \tweak property value grob.  Simple as that.  It's just
alternative syntax for \once\override grob.property = value which is
more interesting when you have an alias like \hide or \omit.

>> I don't see a better solution here.  Obviously, or I would not have
>> converged to the behavior implemented in October.  Unless you can
>> come up with anything that has not already been considered and/or
>> discussed, this is not going to lead anywhere.
>
> well, i have one idea that i think wasn't quite discussed.  However, i
> suppose i have to learn more about parser and related things to have a
> meaningful discussion, so i suppose this has to wait.

That sounds like you are planning for something that can't be made to
work with the current parser and music functions.  Which probably means
that it is going to make things nicer at the price of making things
considerably more complex.  Giving me a good hunch how the meaningful
discussion is going to go.

We are living in the best of all conceivable worlds.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[Janek Warchoł]

Hi,

2013/4/23 David Kastrup :
> Janek Warchoł  writes:
>> Btw, issue 2540 made it possible to write
>>
>> \version "2.17.3"
>> { < \tweak Accidental #'color #red cis' fis'' > }
>>
>> which colored the sharp of the cis.  Is it possible to achieve the
>> same goal with newer versions?  I've tried some combinations with
>> 2.17.13 but they failed.
>
> If you don't want to read the manual, you can use convert-ly.

Hmm.  I tried, but apparently Frescobaldi tricked me - it appeared as
if the conversion didn't change anything.  Apologies - i've tried
doing this directly with command line, which worked and gave me

\version "2.17.3"
{ < \tweak Accidental.color #red cis' fis'' > }

which, quite frankly, is exactly what i hoped for!  Woohoo!  Now we're
talking.  So, current \tweak syntax is actually

\tweak grob-property-path value grob-or-music
(not \tweak property value grob-or-music as i mistakenly thought)

and _that_ makes my day!  I wish that someone told me that when i
asked about it in https://codereview.appspot.com/8647044/#msg2 - it
would save us a lot of time.

>>> I don't see a better solution here.  Obviously, or I would not have
>>> converged to the behavior implemented in October.  Unless you can
>>> come up with anything that has not already been considered and/or
>>> discussed, this is not going to lead anywhere.
>>
>> well, i have one idea that i think wasn't quite discussed.  However, i
>> suppose i have to learn more about parser and related things to have a
>> meaningful discussion, so i suppose this has to wait.
>
> That sounds like you are planning for something that can't be made to
> work with the current parser and music functions.  Which probably means
> that it is going to make things nicer at the price of making things
> considerably more complex.

Well, i suppose that it's something that wouldn't actually be very
complex, but from the past experience i expect that i'd probably fail
to formulate my thoughts 100% precisely, and then we'd spend a week
arguing over something different than the suggestion i actually had in
mind. :P

best,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[David Kastrup]

Janek Warchoł  writes:

> Hi,
>
> 2013/4/23 David Kastrup :
>> Janek Warchoł  writes:
>>> Btw, issue 2540 made it possible to write
>>>
>>> \version "2.17.3"
>>> { < \tweak Accidental #'color #red cis' fis'' > }
>>>
>>> which colored the sharp of the cis.  Is it possible to achieve the
>>> same goal with newer versions?  I've tried some combinations with
>>> 2.17.13 but they failed.
>>
>> If you don't want to read the manual, you can use convert-ly.
>
> Hmm.  I tried, but apparently Frescobaldi tricked me - it appeared as
> if the conversion didn't change anything.  Apologies - i've tried
> doing this directly with command line, which worked and gave me
>
> \version "2.17.3"
> { < \tweak Accidental.color #red cis' fis'' > }
>
> which, quite frankly, is exactly what i hoped for!  Woohoo!  Now we're
> talking.  So, current \tweak syntax is actually
>
> \tweak grob-property-path value grob-or-music
> (not \tweak property value grob-or-music as i mistakenly thought)

And if you really put a grob name last, you don't get a tweak but an
override.  Which does not make much sense unless you use \tweak in music
functions like \hide or \omit when it will come in handy.

> and _that_ makes my day!  I wish that someone told me that when i
> asked about it in https://codereview.appspot.com/8647044/#msg2 - it
> would save us a lot of time.

Uh, it was not at all relevant to your question?  You explicitly state
there "I understand that grob-name is at the end because it's optional,
and we want to omit it when we're using \offset as a tweak."

You claim that you understand the reason, and you explicitly state the
reason.  That does not exactly make it easy to guess that you don't
understand the reason.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[Janek Warchoł]

2013/4/23 David Kastrup :
> Janek Warchoł  writes:
>
>> Hi,
>>
>> 2013/4/23 David Kastrup :
>>> Janek Warchoł  writes:
 Btw, issue 2540 made it possible to write

 \version "2.17.3"
 { < \tweak Accidental #'color #red cis' fis'' > }

 which colored the sharp of the cis.  Is it possible to achieve the
 same goal with newer versions?  I've tried some combinations with
 2.17.13 but they failed.
>>>
>>> If you don't want to read the manual, you can use convert-ly.
>>
>> Hmm.  I tried, but apparently Frescobaldi tricked me - it appeared as
>> if the conversion didn't change anything.  Apologies - i've tried
>> doing this directly with command line, which worked and gave me
>>
>> \version "2.17.3"
>> { < \tweak Accidental.color #red cis' fis'' > }
>>
>> which, quite frankly, is exactly what i hoped for!  Woohoo!  Now we're
>> talking.  So, current \tweak syntax is actually
>>
>> \tweak grob-property-path value grob-or-music
>> (not \tweak property value grob-or-music as i mistakenly thought)
>
> And if you really put a grob name last, you don't get a tweak but an
> override.

So, a \tweak gets, so to speak, "internally transformed to an
override"?  This is cool!!

>> and _that_ makes my day!  I wish that someone told me that when i
>> asked about it in https://codereview.appspot.com/8647044/#msg2 - it
>> would save us a lot of time.
>
> Uh, it was not at all relevant to your question?  You explicitly state
> there "I understand that grob-name is at the end because it's optional,
> and we want to omit it when we're using \offset as a tweak."
>
> You claim that you understand the reason, and you explicitly state the
> reason.  That does not exactly make it easy to guess that you don't
> understand the reason.

bang.
Well, in that sentence i had used the word "understand" in the meaning
"infer" (that's a valid use according to the dictionary
http://www.thefreedictionary.com/understand).  Apparently i should've
used some other word instead, like "suppose".
lol :P
It's amazing that i'd been almost right in that comment...  I mean, it
_is_ true that "Since David K's change that allowed to use
dot-separated list for specyfying grobs "together" with properties, we
could process both the property and grobname as one argument".

best,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[David Kastrup]

Janek Warchoł  writes:

> 2013/4/23 David Kastrup :
>> Janek Warchoł  writes:
>>
>>> Hi,
>>>
>>> 2013/4/23 David Kastrup :
 Janek Warchoł  writes:
> Btw, issue 2540 made it possible to write
>
> \version "2.17.3"
> { < \tweak Accidental #'color #red cis' fis'' > }
>
> which colored the sharp of the cis.  Is it possible to achieve the
> same goal with newer versions?  I've tried some combinations with
> 2.17.13 but they failed.

 If you don't want to read the manual, you can use convert-ly.
>>>
>>> Hmm.  I tried, but apparently Frescobaldi tricked me - it appeared as
>>> if the conversion didn't change anything.  Apologies - i've tried
>>> doing this directly with command line, which worked and gave me
>>>
>>> \version "2.17.3"
>>> { < \tweak Accidental.color #red cis' fis'' > }
>>>
>>> which, quite frankly, is exactly what i hoped for!  Woohoo!  Now we're
>>> talking.  So, current \tweak syntax is actually
>>>
>>> \tweak grob-property-path value grob-or-music
>>> (not \tweak property value grob-or-music as i mistakenly thought)
>>
>> And if you really put a grob name last, you don't get a tweak but an
>> override.
>
> So, a \tweak gets, so to speak, "internally transformed to an
> override"?  This is cool!!

Well, it no longer has music to apply to, only a grob name.  I am not
enthused about the resulting syntax/order when one _does_ need to
specify properties or subproperties for a command using \tweak
internally when employing it as an override.

But at least as a tweak, it looks nice.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[Janek Warchoł]

2013/4/23 David Kastrup :
> Janek Warchoł  writes:
>> So, a \tweak gets, so to speak, "internally transformed to an
>> override"?  This is cool!!
>
> Well, it no longer has music to apply to, only a grob name.  I am not
> enthused about the resulting syntax/order when one _does_ need to
> specify properties or subproperties for a command using \tweak
> internally when employing it as an override.
>
> But at least as a tweak, it looks nice.

I've just read the definition of \tweak.  From what i understand, it's
entirely possible to write a function that will do a tweak if one of
its arguments is a symbol, and do an override if that argument is a
symbol-list?  Something like this:

foo =
#(define-music-function (parser location prop value music)
   (symbol-list-or-symbol? scheme? music?)
   (if (symbol? item)
   #{ \tweak #prop #value #music #}
   #{ \once\override #(append a b) = #value #}))

{
  \foo NoteHead.color #red % use as \once\override
  c'1-\foo #color #red -> % use as \tweak
}

best,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[David Kastrup]

Janek Warchoł  writes:

> 2013/4/23 David Kastrup :
>> Janek Warchoł  writes:
>>> So, a \tweak gets, so to speak, "internally transformed to an
>>> override"?  This is cool!!
>>
>> Well, it no longer has music to apply to, only a grob name.  I am not
>> enthused about the resulting syntax/order when one _does_ need to
>> specify properties or subproperties for a command using \tweak
>> internally when employing it as an override.
>>
>> But at least as a tweak, it looks nice.
>
> I've just read the definition of \tweak.  From what i understand, it's
> entirely possible to write a function that will do a tweak if one of
> its arguments is a symbol, and do an override if that argument is a
> symbol-list?  Something like this:
>
> foo =
> #(define-music-function (parser location prop value music)
>(symbol-list-or-symbol? scheme? music?)
>(if (symbol? item)
>#{ \tweak #prop #value #music #}
>#{ \once\override #(append a b) = #value #}))

Uh, this is such a confused mess that I propose you first make this work
before discussing it.

What's a, b, item?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: order of function arguments

[Janek Warchoł]

2013/4/23 David Kastrup :
> Janek Warchoł  writes:
>
>> 2013/4/23 David Kastrup :
>>> Janek Warchoł  writes:
 So, a \tweak gets, so to speak, "internally transformed to an
 override"?  This is cool!!
>>>
>>> Well, it no longer has music to apply to, only a grob name.  I am not
>>> enthused about the resulting syntax/order when one _does_ need to
>>> specify properties or subproperties for a command using \tweak
>>> internally when employing it as an override.
>>>
>>> But at least as a tweak, it looks nice.
>>
>> I've just read the definition of \tweak.  From what i understand, it's
>> entirely possible to write a function that will do a tweak if one of
>> its arguments is a symbol, and do an override if that argument is a
>> symbol-list?  Something like this:
>>
>> foo =
>> #(define-music-function (parser location prop value music)
>>(symbol-list-or-symbol? scheme? music?)
>>(if (symbol? item)
>>#{ \tweak #prop #value #music #}
>>#{ \once\override #(append a b) = #value #}))
>
> Uh, this is such a confused mess that I propose you first make this work
> before discussing it.
>
> What's a, b, item?

OMG, i can't believe i've sent such an unholy mess.  Sorry - i got too
excited, apparently.
I meant something like this (unfortunately, this doesn't compile under
2.17.13, saying that i have to be in Lyricmode for NoteHead - but at
least it makes some sense):

foo =
#(define-music-function (parser location prop value music)
   (symbol-list-or-symbol? scheme? music?)
   (if (symbol? prop)
   #{ \tweak #prop #value #music #}
   #{ \once\override #prop = #value #}))

{
  \foo NoteHead.color #red
  c'1-\foo #color #red ->
}

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Document the use of \temporary (2938) (issue 8859044)

[tdanielsmusic]

https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):

https://codereview.appspot.com/8859044/diff/1/Documentation/extending/programming-interface.itely#newcode413
Documentation/extending/programming-interface.itely:413: will then pop
the previous value.
On 2013/04/23 13:27:45, dak wrote:

On 2013/04/23 13:19:05, janek wrote:
> Shouldn't this be "pop the new value" or "pop the temporarily

overridden

value"?



Indeed.  It is probably not overly helpful speaking of popping values

since that

is ambiguous between "getting them" and "discarding them".  What is

popped is

actually the stack itself.  If we want to avoid too much programmer

lingo, we

probably would rather write something like



"The use of @code{\temporary} causes the (usually set)

@code{pop-first} property

in the override to be cleared, so the previous value is not popped off

the

property stack before pushing the new value onto it.  When a

subsequent

@code{\revert} pops off the temporarily overriden value, the previous

value will

reemerge."


Much clearer!  Thanks, both!

Done

Trevor

https://codereview.appspot.com/8859044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES: Countdown for April 25th - 19:00 GMT

[James]

Hello,

I'll be able to squeeze in one more countdown in 2 instead of 3 days which
I'll do.


This might not be enough for everyone to review, so I'll hope those devs
involved will make allowances for that.

There's a mix of doc and complex (seemingly) patches that are going to be
easy/difficult to review, but I am not expert enough to pick and choose
that that are 'probably ok' for a 2 day countdown vs those that are not.

I'll leave it to you.

Anyway, enough talk. Onwards and Upwards!

*Countdown – April 25th 2013 – 19:00 GMT* *
* *
* *
* *
*




 
3309
Enhancement
Janek Warchol Push Patch: change OctavateEight to ClefModifier
3280
Documentation
Trevor Daniels Push NR and allocating a tweak
3313
Enhancement
David Nalesnik Push Patch: Add the command \offset to LilyPond
3207
Ugly
Mike Solomon Push too extreme skylining for \tempo text   Regression
3175
Documentation
Trevor Daniels Push [DOC] Notation Reference 1.6.2 Modifying single staves
- customizing staff positions
3159
Documentation
Trevor Daniels Push Rewrite \transposition examples in notation manual
 
3080
Documentation
Trevor Daniels Push NR 1.2.3 Upbeats confusing explanation of
measurePosition
3098
Documentation
Trevor Daniels Push Parser diagnostics failing to recognise \on-the-fly
arguments as procedure type




 
3327
Enhancement
Mike Solomon countdown Patch: Avoids direction checking for cross-staff
side-support-elements
3308
Enhancement
Janek Warchol countdown Patch: Add changes entry for Mike's work on
skylines.  
3279
Ugly
keith O'Hara countdown space consecutive tempo marks
3133
Documentation
Trevor Daniels countdown A music expression cannot be followed by a tie
3103
Documentation
Trevor Daniels countdown Book title showing up on every score in a songbook
3078
Documentation
Trevor Daniels countdown NR 1.2.3 Unmetered music: cadenza and bars
2902
Documentation
Trevor Daniels countdown Review and improve documentation of \paper wrt
book/bookpart




 
3328
Enhancement
 review Patch: Cleanup from "Make midiMaximumVolume take effect ..."
3320
Ugly
Mike Solomon review Dynamic spanner vertical

Re: Add the command \offset to LilyPond (issue 8647044)

[david . nalesnik]

On 2013/04/23 13:14:23, janek wrote:

anyway, this patch LTGM.


Thanks, Janek!

The patch has passed countdown, but in view of the fact that a stable
release is on the horizon, it may not be appropriate to push it at this
time.

On the other hand, an argument for pushing it right away might be to
guard it against loss of functionality, as happened recently regarding
Stem.length and Y-offset for certain grobs.

What do you think about this?  If it's OK to push, I can supply a patch
to whoever is willing to take it on.

-David

https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add the command \offset to LilyPond (issue 8647044)

[dak]

On 2013/04/23 19:03:18, david.nalesnik wrote:

On 2013/04/23 13:14:23, janek wrote:
> anyway, this patch LTGM.



Thanks, Janek!



The patch has passed countdown, but in view of the fact that a stable

release is

on the horizon, it may not be appropriate to push it at this time.



On the other hand, an argument for pushing it right away might be to

guard it

against loss of functionality, as happened recently regarding

Stem.length and

Y-offset for certain grobs.


Huh?  I don't understand that argument.  On the other hand, the patch is
missing a Changes entry and any integration into the user documentation,
so it is mostly inaccessible to users anyway (and the means to
discuss/review its interface design are limited) and there seems little
point to include it in this state.  If we don't have documentation for
the next unstable release, the chances for translations etc to arrive
timely are slim.

https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add the command \offset to LilyPond (issue 8647044)

[david . nalesnik]

On 2013/04/23 19:38:09, dak wrote:

On 2013/04/23 19:03:18, david.nalesnik wrote:
> On 2013/04/23 13:14:23, janek wrote:
> > anyway, this patch LTGM.
>
> Thanks, Janek!
>
> The patch has passed countdown, but in view of the fact that a

stable release

is
> on the horizon, it may not be appropriate to push it at this time.
>
> On the other hand, an argument for pushing it right away might be to

guard it

> against loss of functionality, as happened recently regarding

Stem.length and

> Y-offset for certain grobs.



Huh?  I don't understand that argument.


I mean simply that future changes would need to take the functionality
of \offset into account.  There's no real guarantee that something isn't
going to be pushed between the present and the date the the stable
release actually comes out that won't affect it.

On the other hand, the patch is missing

a Changes entry and any integration into the user documentation, so it

is mostly

inaccessible to users anyway (and the means to discuss/review its

interface

design are limited) and there seems little point to include it in this

state.

If we don't have documentation for the next unstable release, the

chances for

translations etc to arrive timely are slim.


I'm not entirely clear what you mean here.  Are you saying that the
patch should be withdrawn and resubmitted with full documentation--if it
is to be considered for the _stable_ release?

Thanks,
David



https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add the command \offset to LilyPond (issue 8647044)

[dak]

Sorry for the late review.


https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly
File input/regression/offsets.ly (right):

https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly#newcode5
input/regression/offsets.ly:5: the @code{\\offset} command.  These
properties are limited to immutable
What does "immutable" mean here?

https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly#newcode8
input/regression/offsets.ly:8: in its default appearance.  The command
is used both as a tweak and an
"demonstrated as a tweak and as an override".  The double "as" is
important, and I'd remove "both" since otherwise the impression arises
that it is both at the same time.

https://codereview.appspot.com/8647044/diff/5001/scm/c++.scm
File scm/c++.scm (right):

https://codereview.appspot.com/8647044/diff/5001/scm/c++.scm#newcode30
scm/c++.scm:30: (every number-pair? x)))
Isn't it dangerous to call "every" on something that is not necessarily
a list?  Like (cons 2 3)?

https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm
File scm/music-functions.scm (right):

https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm#newcode2103
scm/music-functions.scm:2103: ; head of the alist.  We reverse the alist
so our search will return
Why would tweak/override add to the _immutable_ properties?  How could
they?  Is there something I don't understand here?

https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Be serious about setstrokeadjust in PostScript primitives (issue 8663044)

[k-ohara5a5a]

Confirming that the .pdf size doubles, but only if we measure relative
to the size of the smaller .pdfs we get if we know to use
-dno-point-and-click.  The time required to process the larger .ps was
less that 1% the total time to compile my test .ly files.

Confirming that the resulting larger .pdf has better and more consistent
line thickness when previewed with Adobe Reader on WinXP.

I had to look for a while to find a PDF previewer that showed the
original problem.  Maybe no-pretty-previews by default?

The Evince shipped with Gnome as DocumentViewer 2.32.0
using poppler/cairo (0.14.4) shows no problem (good previews with
visually consistent line thicknesses at all zoom).  SumatraPDF, using
the MuPDF engine, shows no problem.  AcroRead on WinXP shows a minor
problem, that only becomes obvious I we turn on the setting "Enhance
Thin Lines".  (I just did a fresh install of Adobe Reader XI and found
"EnhanceThinLines" is set by default.)
Once I found the problem, this patch did fix it.

https://codereview.appspot.com/8663044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add the command \offset to LilyPond (issue 8647044)

[dak]

https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm
File scm/music-functions.scm (right):

https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm#newcode2103
scm/music-functions.scm:2103: ; head of the alist.  We reverse the alist
so our search will return
On 2013/04/23 20:24:57, dak wrote:

Why would tweak/override add to the _immutable_ properties?  How could

they?  Is

there something I don't understand here?


To answer myself: the basic properties would contain overrides (set
there from the respectively changed context property) but not tweaks
(which are applied after initialization of the grob).

"If our search returns an anonymous procedure" is quite strained.  We
don't need to _speculate_ about the identity of the anonymous procesure.
 If we want to be sure, we can just remember it:

(define (offsetter property offsets)
  (define (self grob)
 ...

and we can now check through both mutable and immutable grob properties,
find self, and look behind self in the aliast to see whether we find
another occurence of the property which, if found, we duly evaluate
recursively.  That should allow multiple offsetter calls to work
recursively.

Huh.  Maybe not the best idea since
\offset Y-offset ... Grob
\offset Y-offset ... Grob
would not accumulate while
\offset Y-offset ... Grob
\temporary\offset Y-offset ... Grob
or even
\offset Y-offset ... Grob
\once\offset Y-offset ... Grob
would.

But still seems better than forgetting all overrides except the first
one (likely in the grob definition).

https://codereview.appspot.com/8647044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Avoids direction checking for cross-staff side-support-elements (issue 8557044)

[k-ohara5a5a]

lgtm

Somewhere I'll have to write down the definition
"cross-staff": true for a grob whose placement or size could depend on
the spacing of staves on the page.


https://codereview.appspot.com/8557044/diff/6001/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):

https://codereview.appspot.com/8557044/diff/6001/lily/side-position-interface.cc#newcode160
lily/side-position-interface.cc:160: // we avoid the circular dependency
by returning true
/* If 'me' is placed relative to any cross-staff element with a
'direction callback defined, the placement of 'me' is likely to depend
on staff-spacing, thus 'me' should be considered 'cross-staff' */

https://codereview.appspot.com/8557044/diff/6001/lily/side-position-interface.cc#newcode169
lily/side-position-interface.cc:169: // as cross-staff. otherwise we do.
if you do not use the vaguest possible words 'element' (for the variable
'me') and 'grob' (for 'elts[i]') and refrain from using 'aligning' to
mean 'aligned' then we might not find this comment impossible to
understand.  otherwise we do.

https://codereview.appspot.com/8557044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Be serious about setstrokeadjust in PostScript primitives (issue 8663044)

[dak]

On 2013/04/23 21:56:07, Keith wrote:

Confirming that the .pdf size doubles, but only if we measure relative

to the

size of the smaller .pdfs we get if we know to use

-dno-point-and-click.  The

time required to process the larger .ps was less that 1% the total

time to

compile my test .ly files.



Confirming that the resulting larger .pdf has better and more

consistent line

thickness when previewed with Adobe Reader on WinXP.



I had to look for a while to find a PDF previewer that showed the

original

problem.  Maybe no-pretty-previews by default?



The Evince shipped with Gnome as DocumentViewer 2.32.0
using poppler/cairo (0.14.4) shows no problem (good previews with

visually

consistent line thicknesses at all zoom).  SumatraPDF, using the MuPDF

engine,

shows no problem.  AcroRead on WinXP shows a minor problem, that only

becomes

obvious I we turn on the setting "Enhance Thin Lines".  (I just did a

fresh

install of Adobe Reader XI and found "EnhanceThinLines" is set by

default.)

Once I found the problem, this patch did fix it.


Evince in Raring Ringtail (upcoming Ubuntu) is
GNOME Document Viewer 3.6.1
and definitely shows the problem.  Libraries are
ii  libcairo2:i386 1.12.14-0ubu i386 The Cairo 2D vector
graphics libr
ri  libpoppler28:i 0.20.5-1ubun i386 PDF rendering library

xpdf (from several versions back, the last one that does not just
segfault) too.

https://codereview.appspot.com/8663044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Avoids direction checking for cross-staff side-support-elements (issue 8557044)

[m...@mikesolomon.org]

On 24 avr. 2013, at 01:06, k-ohara5...@oco.net wrote:

> lgtm
> 
> Somewhere I'll have to write down the definition
> "cross-staff": true for a grob whose placement or size could depend on
> the spacing of staves on the page.

It's not quite that.  In the definition above, a treble clef on the 5th staff 
of a system is cross-staff because its placement depends on what is contained 
in the systems above.  What will not change is its placement with respect to 
its staff.  I like "Any grob that is not the element of a vertical axis group 
or whose relative extent with respect to the vertical axis group of which it is 
an element changes as a result of how far apart two or more vertical axis 
groups are." This opens up the definition to all vertical axis groups (i.e. 
Dynamics, ChordNames). But it is obviously too technical for a docstring.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Point and Click does not work on Windows

[ArnoldTheresius]

Phil Holmes-2 wrote
> - Original Message - 
> From: "David Kastrup" <

> dak@

> >
> To: <

> lilypond-devel@

> >
> Sent: Tuesday, April 23, 2013 1:08 PM
> Subject: Re: Point and Click does not work on Windows
> 
> 
>> ArnoldTheresius <

> Arnold.Wendl@

> > writes:
>>> Who will (and can off course) initiate the modification to the
>>> installer and the lilypond-invoke-editor script?
>>
>> The latter question seems of the make-or-break variety, indeed.
> 
> The strict answer is "anyone with push access to Graham's github account". 
> That includes me and Julien and probably others.  To modify the installer 
> requires NSIS experience.  I've essentially none of that, although I think
> I 
> was the last person to mess with it.  If either Arnold or Eluze can create
> a 
> patch, I'd be happy to test it once my rush of college work is over (end
> of 
> May).
> 
> --
> Phil Holmes 
> 
> 
> ___
> lilypond-devel mailing list

> lilypond-devel@

> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Thank you Phil Holmes,

this time scheule sounds good to me.
I'll have some time off from this development and expect to continue working
on this issue on 2013-05-05.

And regarding the 'start in background or not' question for the different
editors, I got another, more simple idea:
- create a textfile named 'editor-launch-test.scm'.
- just enter the command line execution to start the editor with the 'goto',
option, e.g.
  /(system "lilypad +3:1 testfile.ly")/
or
  /(system "jedit -reuseview testfile.ly +line:3")/
- the execute it in the windows command line. Due to the lilypond
installation you should just enter the filename »editor-launch-test.scm« in
the command line and it will be interpreted by guile.
-- then check when the command prompt in this 'dos shell' comes back -
immediately after the editor started, or only after the editor terminated.
So I ask you, if you have allready installed one of these editors on your
windows computer you also installed lilypond (and no one other has allready
checked this editor), then try to execute this check and let us know the
result.
I have gvim installed and therfore allready tested (and lilypad too, of
course).

ArnoldTheresius



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Point-and-Click-does-not-work-on-Windows-tp115986p144987.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel