Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread David Kastrup 
Paul  writes:

> On 07/17/2017 02:14 PM, David Kastrup wrote:
>
>> Currently there is a bit of a lull (not entirely graceful due to me not
>> keeping up with things all the best), so the time seems convenient.
>
> No objections here.  What's the latest thinking/status for issue 3884?
> Anything I can / should do?
>
> Patch: Add on-page-greater-than, -less-than (on-the-fly)
> https://sourceforge.net/p/testlilyissues/issues/3884/
>
>> There are a few "critical" bugs outstanding, the "Changes" document
>> should be reordered to be systematic rather than in reverse time order,
>> and I'd want to add a bit of syntactic Scheme and LilyPond sugar of the
>>
>> \markup blabla = \markup \with-color #red \etc
>
> I like the goal of defining named markup functions via \etc  but I
> find this syntax a bit odd, with the `=` to the right of `\markup` .
> I can't think of other cases in LilyPond like this:
>
> \onething another =
>
> where a '\' is to the left of an `=`.

Actually, I have code where you can put a lot to the left of an equals
sign when defined via a function with setter.  It had some parser
conflicts however, basically because

{ a = b }

is actually valid music (try figuring out why).

> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`.

You can only use markup functions when refered to in markup mode, so it
makes sense to me to define them in markup mode.

> Are there other options that wouldn't introduce this new pattern?
> Would something like this work?
>
> \define-markup blabla \markup \with-color #red \etc

A very strange reserved word.

-- 
David Kastrup

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

Re: LilyDevOS, a LilyDev container + full VM image

2017-07-19 Thread Federico Bruni 



Il giorno lun 17 lug 2017 alle 16:58, Federico Bruni 
 ha scritto:


Good point. I don't think that there's even any browser in the 
container now.
Perhaps I may install a text browser and set the BROWSER environment 
variable.

I have a small patch to send, I'll let you know how it works.







I've tried lynx, but it's not working correctly.
It ends up with this link: 
https://codereview.appspot.com/get-access-token?port=8001

but does not go beyond this and I have to cancel with Ctrl+C.

If you want to give it a try:

sudo dnf install lynx



Don't give it a try.
w3m and elinks accept cookies by default, so login to google is easy 
and saved across different sessions.


I just need to check if the redirect from /get-access-token?port=8001 
works.


I want to avoid installing a regular browser, as it would add some 
dependencies and increase the final size of the container.





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

Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread David Kastrup 
Federico Bruni  writes:

> Il giorno lun 17 lug 2017 alle 19:14, David Kastrup  ha
> scritto:
>> Other things up for cherry-picking are documentation changes and
>> their translations. Since translations usually are done in "bulk",
>> it would make sense to only translate stuff in the stable 2.20
>> branch in the interregnum: that way the translation branch can be
>> merged (rather than individual parts cherry-picked) into the stable
>> branch until the stable branch gets released.
>
> So when you create the stable/2.20 branch, Jean-Charles or Paco will
> merge that branch (instead of master) into the translation branch; and
> translators will keep working on the translation branch as usual.
>
> Is it correct?

Yes, I think this is what should make sense.  I'll do so today.

-- 
David Kastrup

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

Re: LilyDevOS, a LilyDev container + full VM image

2017-07-19 Thread Federico Bruni 
Il giorno lun 17 lug 2017 alle 9:58, Federico Bruni 
 ha scritto:

Thanks Paul, I'll update the README.


I've now updated the instructions about the container.

I've also added instructions on setting up the virtual machine in 
libvirt (i.e. also GNOME Boxes and virt-manager) with a single command.





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

Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread Paul 

On 07/17/2017 02:14 PM, David Kastrup wrote:


Currently there is a bit of a lull (not entirely graceful due to me not
keeping up with things all the best), so the time seems convenient.


No objections here.  What's the latest thinking/status for issue 3884?  
Anything I can / should do?


Patch: Add on-page-greater-than, -less-than (on-the-fly)
https://sourceforge.net/p/testlilyissues/issues/3884/


There are a few "critical" bugs outstanding, the "Changes" document
should be reordered to be systematic rather than in reverse time order,
and I'd want to add a bit of syntactic Scheme and LilyPond sugar of the

\markup blabla = \markup \with-color #red \etc


I like the goal of defining named markup functions via \etc  but I find 
this syntax a bit odd, with the `=` to the right of `\markup` .  I can't 
think of other cases in LilyPond like this:


\onething another =

where a '\' is to the left of an `=`.  It's usually `a = b` or `\a b` 
but not `\a = b` or `\a b = c`.


Are there other options that wouldn't introduce this new pattern? Would 
something like this work?


\define-markup blabla \markup \with-color #red \etc


variety in order to define named markup functions via \etc .  Basically,
this would split define-markup-command into a definition part called by

\markup blabla = ...

and a function part, say
(markup-lambda (layout props arg) (markup?)
#:properties )

that can be generated by a \markup ... \etc expression or other means.

Basically, that's mainly for avoiding the current "ugh" of

blabla-markup = \markup ... \etc


I agree this is "ugh".

-Paul



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

Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread Dan Eble 

> On Jul 19, 2017, at 15:19, David Kastrup  wrote:
> 
> Paul > writes:
> 
>> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`.
> 
> You can only use markup functions when refered to in markup mode, so it
> makes sense to me to define them in markup mode.

The phrase “define them in markup mode” suggests this to me:

\markup { blabla = \with-color #red \etc }
— 
Dan

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

Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread Simon Albrecht 

On 20.07.2017 00:45, Dan Eble wrote:

On Jul 19, 2017, at 15:19, David Kastrup  wrote:

Paul > writes:


It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`.

You can only use markup functions when refered to in markup mode, so it
makes sense to me to define them in markup mode.

The phrase “define them in markup mode” suggests this to me:

\markup { blabla = \with-color #red \etc }


Now we’re brainstorming:

\markup { \define blabla \with-color #red \etc }
\markup { \define { blabla = \with-color #red \etc } }

This is half-serious at most.

Best, Simon

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

Re: Any objections to branching off a stable branch for 2.20?

2017-07-19 Thread David Kastrup 
Dan Eble  writes:

>> On Jul 19, 2017, at 15:19, David Kastrup  wrote:
>> 
>> Paul > writes:
>> 
>>> It's usually `a = b` or `\a b` but not `\a = b` or `\a b = c`.
>> 
>> You can only use markup functions when refered to in markup mode, so it
>> makes sense to me to define them in markup mode.
>
> The phrase “define them in markup mode” suggests this to me:
>
>   \markup { blabla = \with-color #red \etc }

markup mode does not take braces.  Braces are for markup lists.
\markup { ... } is short for \markup \line { ... } and this really makes
a mess of your suggestion.

I mean, bikeshedding is nice but I haven't yet seen a proposal here that
isn't a major stepback.

-- 
David Kastrup

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