Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
On Oct 23, 2011, at 11:26 PM, d...@gnu.org wrote:
Reviewers: Bertrand Bordage,
Message:
On 2011/10/23 21:08:09, Bertrand Bordage wrote:
LGTM. You'll be happy to know that Mike and I are currently trying to
get rid
of \markuplines, so that there will only be a \markup command.
No, I am not happy, since for example fret markings in tabulatures are a
perfect match for markup lists (and calling them markuplines is quite
obscuring this wonderful way of defining them).
The idea is not to get rid of the functionality, but rather the nomenclatural
distinction. The problem is that, in LilyPond markup-speak, there is not a
clear division between creating content, shaping content, and laying content
out. Markups commands like \simple, \note etc. deal with either the creation
of content. \italic, \bold etc. deal with its shaping. And \justify, \line
deal with its layout on the page. markuplist (née markuplist) is a particular
manifestation of this problem on the page level that implements something not
unlike Java Swing's box layout (fancier because it allows for page breaks).
But one could imagine a host of layout managers that deal with the layout of
markups (and scores) on the page, and it would not be a good idea to hardcode
these into the parser (markuphorizontallist,
markuplistexceptwhenmarkupislargerthanthreecentimeterswideinwhichcaseitshouldnotbealist,
etc. as commands). Rather, \markup should be the only command in the game,
and all of the layout managers should be declared within the markup bloc.
It seems like a good representation of any markup, be it top-level or in a text
script, would be a Prob that has three variables:
SCM layout_manager_
vectorSCM transformations_
vectorSCM elements_
\markup { \column { \italic foo bar }} would use line as its layout manager and
have two elements, one markup that used nothing as its layout manager (markups
with 1 element cannot have layout managers) and had no transformations and one
markup that used nothing as its layout manger and had an italic transformation.
In this representation, box-layout-across-pages could be a layout manager that
works like markuplines. The page breaker would take all top level markups,
check the layout managers, and automatically create chunks based on the layout
manager being used.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
On Oct 24, 2011, at 8:57 AM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
\markup { \column { \italic foo bar }} would use line as its layout
manager and have two elements, one markup that used nothing as its
layout manager (markups with 1 element cannot have layout managers)
and had no transformations and one markup that used nothing as its
layout manger and had an italic transformation.
In this representation, box-layout-across-pages could be a layout
manager that works like markuplines. The page breaker would take all
top level markups, check the layout managers, and automatically create
chunks based on the layout manager being used.
Will
z = \markuplist { a b c }
\markup { \concat \z }
still work? That is one of the reasons I want \markuplist rather than
\markuplines since it has nothing to do whatsoever with lines before
it actually gets put into a context wanting to interpret it as such.
Ah, I see what you mean.
Yes, this makes sense. A list of markups would get passed to a layout manager
that would deal with it.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
\markup* and Guile V2 - was Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite gang, Here is a bulletin from the Guile V2 migration cave. I am currently brewing a patch for Tracer 1686. The markup facility as written is a major PITA when running with Guile V2, and is currently blocking progress on this patch. 1. The markup facility code needs to be in a Scheme module (scm markup-facility-defs), or (scm markup-macros) or some such for clean backwards compatibility between Guile V1.8 and Guile 2. This is so that lily.scm can load all the things in the current load list using either Guile 1.8 or Guile V2 and can also byte-compile each loaded file using Guile V2 so that the compiled file can be loaded next time LilyPond fires up to gain performance. 2. Using a module for markup exposes brittleness in the markup code when using Guile V2. Basically I have moved all the declarations in markup-macros and markup to markup-macros.scm, which defines the new (scm markup-macros) module. There is a (use-modules (scm markup-macros) call in lily.scm. Guile V2 is fussier about things like forward-referencing macros and syntax forms before you declare them (i.e. using lazy bindings for macros). 2.1 We can fix things with macros declared at Scheme level by moving declarations to other .scm files and juggling the load order in lily.scm. 2.2 However, things get nastier when we get into the define-markup-commands.scm file and using the markup, markup*, define-markup-command and define-markup-command-list macros. Here we are doing on-the-fly parsing and interpreting and things tend to fall over under Guile V2's stricter régime. 2.2.1 Firstly, the commands in the file have to be re-ordered so that the #markup forms are not referenced before they are used. E.g. #line form is used internally in procedure calls contained within a define-markup-commmand macro for (define-markup-command draw-line ...) before (define-markup-command line) is declared. There are several more examples within the file. 2.2.2 If things are not in the right order you may get lucky and get a fairly unhelpful message Not a markup command: markup. This is the call to lookup-markup-command failing to return a pair within compile-markup-command, which is called from compile-all-markup-commands, which is called from the markup or markup*, which may or may not have been called recursively from higher-level define-markup-commandmumble call. 2.2.3 Some of the definitions just give you a gnostic source expression failed to match any pattern in form blah which may imply we're running into macro hygiene issues. 2.3 We may need think about using using (define-syntax for the macro definitions in the markup facility if hygiene is indeed an issue. This is just to let you know if you're planning on major surgery on the syntax front, the markup module issue needs to be addressed as well. Hope this informs your discussions about changes to markup and if any of you have any insights into what I've found while while working I'd appreciate your input, as I'm getting a bit stuck. I want to be able to concentrate on sorting out the changes to lily.scm and main.cc and validating running up lily under Guile V2. For me the markup facility is a bit of a side issue. Cheers, Ian Hulin On 23/10/11 22:08, bordage.bertr...@gmail.com wrote: LGTM. You'll be happy to know that Mike and I are currently trying to get rid of \markuplines, so that there will only be a \markup command. http://codereview.appspot.com/5312050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \markup* and Guile V2 - was Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
Ian Hulin i...@hulin.org.uk writes:
Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite
gang,
Here is a bulletin from the Guile V2 migration cave.
I am currently brewing a patch for Tracer 1686.
The markup facility as written is a major PITA when running with Guile
V2, and is currently blocking progress on this patch.
My personal take on this: I tend towards making #{ ... #}, which
executes more or less on the macro level, do the job of a macro. Namely
translate its contents into Scheme. You can already use #{ \markup
... #} for getting markup expressions, but if you use this inside of a
Scheme definition, the Lilypond parsing happens at the time of
execution.
The point being that the whole markup macro system can be junked and
replaced by #{ \markup ... #}.
That would not exactly be a minor change. At my current rate of
progress, it will be months before I reach that milestone, and I am
already spending much more time on Lilypond than would be compatible
with sustaining a living.
I agree with you (or if I am putting words in your mouth here, at least
with Guile V2) that the high involvement of macros in markups is a wart
concerning Lilypond's programming interface. I'd prefer replacing its
programming interface with #{ \markup ... #} rather than yet another
syntax to be learnt.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)
LGTM. You'll be happy to know that Mike and I are currently trying to get rid of \markuplines, so that there will only be a \markup command. http://codereview.appspot.com/5312050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
