Re: Allow quoted strings as Scheme arguments to markup commands (issue 331820043 by d...@gnu.org)

2017-10-06 Thread thomasmorley65 

On 2017/10/06 22:00:07, dak wrote:

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py

File python/convertrules.py (right):



https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#newcode3963

python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
On 2017/10/06 21:37:47, Malte Meyn wrote:
> Isn’t this list of markup commands with string arguments far from

complete?


Likely.  It was cooked up on the basis of a git grep call, I think



 git grep '\\markup.*#"'




> What
> about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
> wordwrap-string-internal, and the accordion commands discant,

freeBass,

stdBass,
> stdBassIV, stdBassV, and stdBassVI?



Some of them certainly are good candidates, as long as their

_first_(!) argument

is the string argument.  Otherwise, the convert-ly expression becomes

a lot more

tricky.


One could probably do something at the lines of:
(pretty-print
  (sort
(map car
  (filter
(lambda (x)
  (let* ((predicates (markup-command-signature (cdr x
(and predicates
 (pair? predicates)
   (eq?
 (procedure-name string?)
 (car (map procedure-name predicates))
(ly:module->alist (resolve-module '(lily)
symbol
 (fret-diagram-markup
  fret-diagram-terse-markup
  harp-pedal-markup
  justify-string-markup
  lookup-markup
  musicglyph-markup
  postscript-markup
  rest-markup
  simple-markup
  tied-lyric-markup
  verbatim-file-markup
  with-url-markup
  wordwrap-string-markup)


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

Re: Allow quoted strings as Scheme arguments to markup commands (issue 331820043 by d...@gnu.org)

2017-10-06 Thread lilypond 

On 2017/10/06 22:00:07, dak wrote:

> What
> about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
> wordwrap-string-internal, and the accordion commands discant,

freeBass,

stdBass,
> stdBassIV, stdBassV, and stdBassVI?



Some of them certainly are good candidates, as long as their

_first_(!) argument

is the string argument.  Otherwise, the convert-ly expression becomes

a lot more

tricky.


Hm, that’s correct, but only two of these candidates don’t have the
string as their first argument:

1. \epsfile starts with two numbers (\epsfile #X #20 #"myfile.eps")
2. \wordwrap-string-internal starts with a boolean
(\wordwrap-string-internal ##t #"This is my string")

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

Re: Allow quoted strings as Scheme arguments to markup commands (issue 331820043 by d...@gnu.org)

2017-10-06 Thread dak 


https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#newcode3963
python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
On 2017/10/06 21:37:47, Malte Meyn wrote:

Isn’t this list of markup commands with string arguments far from

complete?

Likely.  It was cooked up on the basis of a git grep call, I think

git grep '\\markup.*#"'



What
about wordwrap-string, eps-file, with-url, lookup, verbatim-file,
wordwrap-string-internal, and the accordion commands discant,

freeBass, stdBass,

stdBassIV, stdBassV, and stdBassVI?


Some of them certainly are good candidates, as long as their _first_(!)
argument is the string argument.  Otherwise, the convert-ly expression
becomes a lot more tricky.

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

Re: Allow quoted strings as Scheme arguments to markup commands (issue 331820043 by d...@gnu.org)

2017-10-06 Thread lilypond 


https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/331820043/diff/20001/python/convertrules.py#newcode3963
python/convertrules.py:3963: str = re.sub
(r'(\\(?:justify-string|musicglyph|harp-pedal|simple|postscript'
Isn’t this list of markup commands with string arguments far from
complete? What about wordwrap-string, eps-file, with-url, lookup,
verbatim-file, wordwrap-string-internal, and the accordion commands
discant, freeBass, stdBass, stdBassIV, stdBassV, and stdBassVI?

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread lilypond 

On 2017/10/06 09:39:11, dak wrote:

I mean exactly what I say: set direction to CENTER (if this would

otherwise

cause problems, temporarily) and call the original callback in order

to

determine staff-position.


I didn’t manage to use these callbacks correctly but maybe my solution
without them is clean enough?


As it stands, it would seem like there is a tedious reprogramming of

the

staff-position callback that is as hard to get right as the original

was, so why

not use the original?


It seems like using 'staff-position for Rests and 'direction for
MultiMeasureRests is sufficient for not having any special cases with
semibrevis and brevis rests.


> This seems to work for MMRs but for Rests it gives
> warnings of the type
> warning: cannot resolve rest collision: rest direction not

set


Suiciding one of the rests likely would not go well with articulations

placed on

it (though those still need some sort of merging with the other?) but

would seem

like the easiest way out.


I tried to suicide them and this resulted in crashes without error
messages; but fortunately it also seems to work with transparent instead
of dead grobs now ;) I tried also setting 'stencil to #f instead of
'transparent to #t but that causes problems with
MultiMeasureRestNumbers.

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

Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?

2017-10-06 Thread Karlin High 
On Thu, Oct 5, 2017 at 7:01 AM, Federico Bruni  wrote:
> Anyway, if we decide that the setup script in LilyDev should include your
> proposal, I'll be happy to see a pull request

https://github.com/fedelibre/LilyDev/pull/8

If you decide against including this, I will be OK with that. Perhaps
5 or so :) new contributors might benefit before the fonts get
included in the LilyDev base distro and this issue self-resolves.
-- 
Karlin High
Missouri, USA

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

Re: make test fails → texi2html (?) error

2017-10-06 Thread Malte Meyn 



Am 06.10.2017 um 17:20 schrieb Federico Bruni:
Il giorno ven 6 ott 2017 alle 16:27, Malte Meyn  
ha scritto:
What’s this? I found the same message in the list archive 
(https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00084.html) 
but I couldn’t find any other hints what to do now. If that helps, my 
texi2html version is 5.0.


That's the problem.
You must use an older version, see:
http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond 


Thanks for the hint. As I use Manjaro Linux (an Arch-based distro) I had 
only looked at the “Other” section.


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

Re: make test fails → texi2html (?) error

2017-10-06 Thread Jean-Charles Malahieude 

Le 06/10/2017 à 16:27, Malte Meyn a écrit :

Hi list,

I tried to compile the regression tests (make test) but this failed with 
the following message in input/regression/collated-files.texilog.log:


Undefined subroutine ::get_index called at 
/home/malte/lilypond/Documentation/lilypond-texi2html.init line 2408.


What’s this? I found the same message in the list archive 
(https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00084.html) but 
I couldn’t find any other hints what to do now. If that helps, my 
texi2html version is 5.0.




You've to downgrade texi2html to version 1.82.
I've tried to upgrade several times, but there are too many things I 
don't understand in our texi2html.init to have it successfully work.


Cheers,
Jean-Charles

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

Re: make test fails → texi2html (?) error

2017-10-06 Thread Federico Bruni 
Il giorno ven 6 ott 2017 alle 16:27, Malte Meyn  
ha scritto:
What’s this? I found the same message in the list archive 
(https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00084.html) 
but I couldn’t find any other hints what to do now. If that helps, 
my texi2html version is 5.0.


That's the problem.
You must use an older version, see:
http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond





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

make test fails → texi2html (?) error

2017-10-06 Thread Malte Meyn 

Hi list,

I tried to compile the regression tests (make test) but this failed with 
the following message in input/regression/collated-files.texilog.log:


Undefined subroutine ::get_index called at 
/home/malte/lilypond/Documentation/lilypond-texi2html.init line 2408.


What’s this? I found the same message in the list archive 
(https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00084.html) 
but I couldn’t find any other hints what to do now. If that helps, my 
texi2html version is 5.0.


Cheers,
Malte

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread dak 

On 2017/10/06 08:42:55, Malte Meyn wrote:

On 2017/10/06 08:19:46, dak wrote:
> Stupid question: is there no way to (re-)use the default callbacks

which know

> about all those little details?  Set `direction` to neutral and call

them for

> advice?



I’m not sure what you mean: Don’t do anything to Y-offset or

staff-position but

set direction to CENTER?


I mean exactly what I say: set direction to CENTER (if this would
otherwise cause problems, temporarily) and call the original callback in
order to determine staff-position.

As it stands, it would seem like there is a tedious reprogramming of the
staff-position callback that is as hard to get right as the original
was, so why not use the original?


This seems to work for MMRs but for Rests it gives
warnings of the type
 warning: cannot resolve rest collision: rest direction not set


Suiciding one of the rests likely would not go well with articulations
placed on it (though those still need some sort of merging with the
other?) but would seem like the easiest way out.


Of course it would be nice if you wouldn’t have to \override

staff-position for

both Rests and MMRs in the engraver because this prohibits a manual

\override by

the user. But there’s this little inconsistency:


The staff-position callback (if any) may already have been replaced by a
cached value: when I talk about the "original callback" I was rather
suggesting calling the respective function directly rather than through
the grob.

Setting "direction" to 0 would just be an expedient to creating a copy
of the grob with direction set to 0 in order to be able to use that
callback function.  It doesn't seem like this should be causing a
problem, but if it does, one can still reset direction afterwards again.

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread lilypond 

On 2017/10/06 08:42:55, Malte Meyn wrote:

But there’s this little inconsistency:



{
   \override Rest.staff-position = 0
   \override MultiMeasureRest.staff-position = 0
   r1
   R1
}


Hm … I don’t know what I thought when I wrote this. This inconsistency
hasn’t to do anything with a situation where the engraver doesn’t touch
staff-position.

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread lilypond 

On 2017/10/06 08:19:46, dak wrote:

Stupid question: is there no way to (re-)use the default callbacks

which know

about all those little details?  Set `direction` to neutral and call

them for

advice?


I’m not sure what you mean: Don’t do anything to Y-offset or
staff-position but set direction to CENTER? This seems to work for MMRs
but for Rests it gives warnings of the type
warning: cannot resolve rest collision: rest direction not set
Of course it would be nice if you wouldn’t have to \override
staff-position for both Rests and MMRs in the engraver because this
prohibits a manual \override by the user. But there’s this little
inconsistency:

{
  \override Rest.staff-position = 0
  \override MultiMeasureRest.staff-position = 0
  r1
  R1
}

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread dak 

On 2017/10/06 08:12:23, Malte Meyn wrote:

Thanks for the suggestions, I’ll apply these fixes, test them, and add

a

regression test.



There’s another issue (already present in the “old”

Merge_rests_engraver):

Single-bar or non-compressed MMRs in 4/2 time are positioned

incorrectly because

the engraver assumes they are semibrevis rests. I will fix that too.


Stupid question: is there no way to (re-)use the default callbacks which
know about all those little details?  Set `direction` to neutral and
call them for advice?

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

Re: Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-06 Thread lilypond 

Thanks for the suggestions, I’ll apply these fixes, test them, and add a
regression test.

There’s another issue (already present in the “old”
Merge_rests_engraver): Single-bar or non-compressed MMRs in 4/2 time are
positioned incorrectly because the engraver assumes they are semibrevis
rests. I will fix that too.

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