PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

2010-06-14 Thread Alexander Kobel

See http://codereview.appspot.com/1689041.

My fix tries to reintroduce the behaviour of 2.13.11 for the issue 
mentioned, before my patch to 
http://www.mail-archive.com/lilypond-devel@gnu.org/msg27098.html, but 
to keep the 2.13.12+ behaviour for more than two elements inside a 
fill-line.
Besides, I tried to tackle the issue I mentioned here: 
http://www.mail-archive.com/lilypond-u...@gnu.org/msg51242.html, which 
is that nested fill-lines used to shift their contents by some amount to 
the right.


I still think that fill-line is badly specified for single arguments, 
but I can't think of any better rationale for it as well.


For some reason, I don't seem to be able to build the regtests; so all 
this should be taken with care, I did not really check if it breaks 
anything.
And once again, please clean up the indentation.  The real sources 
just look like a complete mess in my Emacs configuration.  I did not try 
to understand this, but rather to guess my tabs and spaces to fit...



Cheers,
Alexander

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


Re: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

2010-06-14 Thread Alexander Kobel

On 2010-06-14 20:24, Neil Puttock wrote:

On 14 June 2010 15:34, Alexander Kobeln...@a-kobel.de  wrote:


Besides, I tried to tackle the issue I mentioned here:
http://www.mail-archive.com/lilypond-u...@gnu.org/msg51242.html, which is
that nested fill-lines used to shift their contents by some amount to the
right.


Heh, I was just about to post a fix for that myself
(http://code.google.com/p/lilypond/issues/detail?id=382), using a
slightly different approach: checking whether the text-width equals or
exceeds line-width.


I thought about that, too, when I first tried to do this several months 
ago.  Not sure why it didn't work out; probably it was just a  vs. = 
issue.
On the other hand, I don't quite get why word-space = 1 is necessary. 
If there's no space left, the user has trouble anyway, and I don't see 
why an arbitrary minimum space should help.  And this should be the 
reason for the shift, IIUC.  Seems like an ugly hack to me, but probably 
there's some reason?


Another question: What does mol stand for in the markup definitions, 
e.g. in general-align in define-markup-commands.scm?



For some reason, I don't seem to be able to build the regtests; so all this
should be taken with care, I did not really check if it breaks anything.


It compiles fine without any breakages.


That's how far I could go.  I just can't get the regression tests, so I 
can't compare if it breaks desired output in other examples than mine.



And once again, please clean up the indentation.  The real sources just
look like a complete mess in my Emacs configuration.  I did not try to
understand this, but rather to guess my tabs and spaces to fit...


Doesn't C-M-\ indent a region for you automatically?


It does, but it also reindents the existing code in a completely 
different manner than what's currently there.



One thing your patch doesn't cover is Reinhold's problem with compound
time signature formatting (see
http://code.google.com/p/lilypond/issues/detail?id=732);


Okay; didn't check this.  Probably one can see it in some regression 
test, then...



I wonder
whether we should just add his suggestion for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably normalize all stacked stencils (read: 
right-column, too) in the same manner.  Which would make sense to me, 
since it's a consistent behaviour, but I suspect this to be incompatible 
with the current design.  And one might require to write \right-align 
\right-column to get the (current?) extent ((- width) . 0), which looks 
clumsy from the typical user's POV.



Cheers,
Alexander

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


Re: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

2010-06-14 Thread Graham Percival
On Mon, Jun 14, 2010 at 10:47:00PM +0200, Alexander Kobel wrote:
 On 2010-06-14 20:24, Neil Puttock wrote:
 One thing your patch doesn't cover is Reinhold's problem with compound
 time signature formatting (see
 http://code.google.com/p/lilypond/issues/detail?id=732);

 Okay; didn't check this.  Probably one can see it in some regression  
 test, then...

This is much better explained in the current git CG, and it'll be
online as soon as I can get 2.13.24 compiled.

Cheers,
- Graham

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


Re: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)

2010-06-14 Thread Neil Puttock
On 14 June 2010 21:47, Alexander Kobel n...@a-kobel.de wrote:

 On the other hand, I don't quite get why word-space = 1 is necessary. If
 there's no space left, the user has trouble anyway, and I don't see why an
 arbitrary minimum space should help.  And this should be the reason for the
 shift, IIUC.  Seems like an ugly hack to me, but probably there's some
 reason?

I don't know why that's there; the default is set in
ly/paper-defaults-init.ly to 0.6.

 Another question: What does mol stand for in the markup definitions, e.g.
 in general-align in define-markup-commands.scm?

It's short for molecule, which used to be the standard name for
stencils in LilyPond.

 That's how far I could go.  I just can't get the regression tests, so I
 can't compare if it breaks desired output in other examples than mine.

Sorry, I meant the regression tests run fine (with `make check'); no
test snippets appear broken.

 It does, but it also reindents the existing code in a completely different
 manner than what's currently there.

Some of the indentation in \fill-line is incorrect (e.g., for the
definition of fill-space), so you're probably improving it. :)

 If we do, we should probably normalize all stacked stencils (read:
 right-column, too) in the same manner.  Which would make sense to me, since
 it's a consistent behaviour, but I suspect this to be incompatible with the
 current design.  And one might require to write \right-align \right-column
 to get the (current?) extent ((- width) . 0), which looks clumsy from the
 typical user's POV.

Hmm, I hadn't considered that, though I wonder if anybody uses \right-column.

Cheers,
Neil

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


fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

2010-06-14 Thread Alexander Kobel

[ Reordering the topics according to general interest. ]

On 2010-06-14 23:14, Neil Puttock wrote:

On 14 June 2010 21:47, Alexander Kobeln...@a-kobel.de  wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. If
there's no space left, the user has trouble anyway, and I don't see why an
arbitrary minimum space should help.  And this should be the reason for the
shift, IIUC.  Seems like an ugly hack to me, but probably there's some
reason?


I don't know why that's there; the default is set in
ly/paper-defaults-init.ly to 0.6.


Uh-oh, so that's another occurence of defaults set in different places 
to different values (in define-markup-commands.scm, and thus the NR, 
it's 1)...  I can hear David's screams... ;-)


Anybody knows if we can remove the minimum space?  IMHO, this will make 
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention 
a separate default for word-space, and the description of \fill-line 
says nothing about it's meaning.  Looks to me like it was copied from 
\line, and been forgotten afterwards.



I wonder whether we should just add his suggestion
[Reinhold: http://code.google.com/p/lilypond/issues/detail?id=732]
for translating the stencil
returned by \center-column onto its left edge (which would simplify
your \fill-line fix.)


If we do, we should probably normalize all stacked stencils (read:
right-column, too) in the same manner.  Which would make sense to me, since
it's a consistent behaviour, but I suspect this to be incompatible with the
current design.  And one might require to write \right-align \right-column
to get the (current?) extent ((- width) . 0), which looks clumsy from the
typical user's POV.


Hmm, I hadn't considered that, though I wonder if anybody uses \right-column.


Definitely, at least in the composer field (though it should not matter 
there, since this one gets nested in a fill-line anyway), but probably 
also for instrument names or a whole bunch of little tweaks and markups. 
 Googling on the LSR gives about 40 hits for center-column and 
right-column, and of course there's thousands of hits on the whole web. 
 It seems very hard to tell in advance how many of those will be 
affected by a change in the extent.




Some of the indentation in \fill-line is incorrect (e.g., for the
definition of fill-space), so you're probably improving it. :)


Ah, this might well be why it does not make too much sense to me right now.
So, usually the Emacs default is okay for Scheme code, too?  The CG only 
says that GNU style is used for C++, but nothing about Scheme.



Another question: What does mol stand for in the markup definitions [...]

It's short for molecule [...]


Ok, thanks.


Sorry, I meant the regression tests run fine (with `make check'); no
test snippets appear broken.


Perfect.  Thanks, too.


Cheers,
Alexander

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


Re: fill-line spec and (center-/right-)column alignment [was: PATCH: issue 1116 (fill-line regression 2.13.11 to 2.13.12+)]

2010-06-14 Thread Alexander Kobel

On 2010-06-15 00:28, Alexander Kobel wrote:

On 14 June 2010 21:47, Alexander Kobeln...@a-kobel.de wrote:

On the other hand, I don't quite get why word-space = 1 is necessary. [...]


Anybody knows if we can remove the minimum space? IMHO, this will make
the code cleaner without causing unexpected trouble on the user side.
Checking the NR A.8.2, \fill-line is the only markup command to mention
a separate default for word-space, and the description of \fill-line
says nothing about it's meaning. Looks to me like it was copied from
\line, and been forgotten afterwards.


I updated the issue on Rietveld with a version of fill-line where 
word-space is completely ignored: http://codereview.appspot.com/1689041.


I think I know now how to properly compile and check the regression 
tests, and I can't spot anything that's broken by this change.  Comments?



Cheers,
Alexander

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