we
> have something to contribute to the conversation but I'm on my phone and
> have 3 minutes. Because manually deleting history on my phone is annoying
> enough that I just won't bother to reply.
I would again like to point out the flip side: When contributing, you
are expec
>> we shouldn’t abandon the standard because it’s difficult to keep it
>>up.
>
> We should abandon the approach when its cost is higher than its
> benefit though. If this is just an occasional nudge, it's fine.
> But if I remember right, I think Werner was talking about
> top-posting (an expressi
Kevin Barry writes:
>> We need to be able to resist Google. You may observe in real time how
>> ready they are to comply with an authoritarian regime: It has long been
>> extremely dangerous how much of a chokehold they have on digital
>> ecosystems. Being complacent with “everyone uses Google, s
essages sent from
>> Gmail.
>
> Google is doing a lot of things that don’t make any sense, and I’m
> quite certain that GNU mailing list standards are based on a better
> understanding on how email should be used than most email
> communication via “normal” mailing software is.
This
Saul Tobin writes:
> I had always thought one of the biggest selling points of FOSS was
> configurability and extensibility. Collapsing or removing the automatically
> included thread history is the sort of job that software should be doing,
> not fallible, habit-prone human users.
When two peop
On 2025-02-11 11:20, Saul Tobin wrote:
what you want people like me to
do if we have something to contribute to the conversation but I'm on my
phone and have 3 minutes.
If the contribution related to a small part of a large message, I would
prefer that a person in this situation wait for a mo
>
> Btw, if I were on my phone, the manipulation necessary to drop the reply
> block would have taken substantially longer than
> typing the message itself.
>
> As Luca
> pointed out, it's not just Google: most of the popular email clients
> behave the same way.
> I think that if this "email e
On Tue, Feb 11, 2025 at 3:52 PM Simon Albrecht
wrote:
> How would I disagree with that? Of course I don’t.
>
I'm sure you don't disagree, there was some rethorics when I said that.
All the same I was also trying to make sure we were talking about the same
thing.
> we shouldn’t abandon the stan
Hi all,
I’m definitely on team “Email Shouldn’t Include Every Word Ever Written In A
Thread”…
> We have mailing list archives in order to preserve reply history, and an
> “expected UI feature” for mailing software would be the ability to display an
> email as part of a thread, or conversation.
On 11.02.25 15:50, Kevin Barry wrote:
Please let's not turn this into a political discussion. As Luca
pointed out, it's not just Google: most of the popular email clients
behave the same way.
It is a political discussion, and has been before my contribution.
Things are interconnected.
There
On 11.02.25 15:48, Luca Fascione wrote:
people and their ideas and their hearts are a higher priority
than the form in which they present their ideas.
How would I disagree with that? Of course I don’t.
The whole matter is not a black-and-white thing, and compromise is
necessary. But it’s very
> We need to be able to resist Google. You may observe in real time how
> ready they are to comply with an authoritarian regime: It has long been
> extremely dangerous how much of a chokehold they have on digital
> ecosystems. Being complacent with “everyone uses Google, so let’s have
> it their wa
Maybe. But it was just an example.
In my view, if a person on this last has something interesting to say and
only 3 minutes to say it,
it should be our priority to take in their contribution vs quibbling over
the form they present their contribution in
(obviously within reason).
I guess my perspe
On 11.02.25 15:07, Luca Fascione wrote:
Btw, if I were on my phone, the manipulation necessary to drop the
reply block would have taken substantially longer than
typing the message itself.
Then you need to get a different mail client to install on your phone (I
think K-9 Mail should be good f
I've said this before. On this issue I agree with Saul.
Email was used in a different way in the past.
It was certainly a substantially more byte-efficient way that what is
currently done.
However the vast majority of email use is now gmail or outlook (and outlook
is _far_ worsem their reply manag
On 09.02.25 17:26, Saul Tobin wrote:
In my humble (and I'm guessing unpopular) opinion, collapsing reply history
included below an email reply is an expected UI feature given that every
email system these days needs to handle messages sent from Gmail.
Google is doing a lot of things that don’t
I assume this is directed at least in part toward me. Including thread
history below the reply is Gmail's built-in behavior. If there were a
setting to change that, I'd be more than happy to use it, but as far as I
know it's not possible to change that default. I can do my best to remember
to manua
It's not particularly my job to say this, but it needs to be said.
Certain people have not been keeping the tradition of the elders in
formatting replies to this list.
* Quote just enough of the message for your reply to be understood.
* Add your responses below the quoted text.
Please adapt.
不得好死
https://codereview.appspot.com/567140045/
Le 25/06/2021 01:40, Dan Eble <[1]d...@faithful.be> a écrit :
On Jun 24, 2021, at 14:17, Jean Abou Samra <[2]j...@abou-samra.fr>
wrote:
Ok, I already simplified it, but it's still too complicated.
Consider approaching from the other direction. If you had only italic,
bold, and
Benkő Pál writes:
> Jean Abou Samra ezt írta (időpont: 2021. jún.
> 24., Cs, 20:17):
>> I'll style \longa in bold too.
>
> \longa is a duration, like 2 in c2; on the other hand 3 in \repeat
> \unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is
> ar
Jean Abou Samra ezt írta (időpont: 2021. jún.
24., Cs, 20:17):
> I'll style \longa in bold too.
\longa is a duration, like 2 in c2; on the other hand 3 in \repeat
\unfold 3 or \time 3/4 is not a duration. now the 4 in \time 3/4 is
arguably a duration, but...
p
On Jun 24, 2021, at 14:17, Jean Abou Samra wrote:
>
> Ok, I already simplified it, but it's still too complicated.
Consider approaching from the other direction. If you had only italic, bold,
and red to work with, how would you use them?
—
Dan
why some functions / variables are printed in bold (\staff-space and
\major are not; assignment to myFunc, mySecondFunc, and myPitch are
not, but their uses are),
Ok, I already simplified it, but it's still too complicated.
All builtin functions are in bold, and anything unknown and
backs
Am Donnerstag, dem 24.06.2021 um 18:36 +0200 schrieb Jean Abou Samra:
> Le 23/06/2021 à 19:03, Jean Abou Samra a écrit :
> > Le 23/06/2021 à 18:53, Dan Eble a écrit :
> > > Not a bad idea, but -1 for the use of light colors on white: silver,
> > > yellow, sky blue, etc.
> > >
> > > What is the mi
On Jun 23, 2021, at 10:33, Jean Abou Samra wrote:
>
> Le 23/06/2021 à 09:58, Jean Abou Samra a écrit :
>> To whet your appetite, a highlighted version of the test
>> file included in the PR is attached.
>
> Not sure why the HTML hasn't gotten through email — on
> the archives and in Dan's mailbo
Le 23/06/2021 à 18:53, Dan Eble a écrit :
On Jun 23, 2021, at 10:33, Jean Abou Samra wrote:
Le 23/06/2021 à 09:58, Jean Abou Samra a écrit :
To whet your appetite, a highlighted version of the test
file included in the PR is attached.
Not sure why the HTML hasn't gotten through email — on
the
Le 23/06/2021 à 09:58, Jean Abou Samra a écrit :
To whet your appetite, a highlighted version of the test
file included in the PR is attached.
Not sure why the HTML hasn't gotten through email — on
the archives and in Dan's mailbox it appears as plain
LilyPond code. Here are additional RTF and
e for inclusion in the BSD-licensed
Pygments.)
Reviews and testing would be appreciated. In particular,
if you would not like to have a later unpleasant surprise
with my aesthetic choices, please give the style a look;
the eventual goal would be to make this used in our
documentation. The setup to s
ed to let you all know that this stuff is under discussion. Note that
I do *not* want the debate to move here (since the MR is easier to find and
link afterwards, and it already started there).
Furthermore, the general style of bar numbers is under question. For
example,
should we print th
Hi,
Le 02/07/2020 à 09:05, Han-Wen Nienhuys a écrit :
You can also do a global cleanup. We have done this in the past, but
it has the disadvantage that it makes history (eg. git-blame) harder
to read.
So, I did the global cleanup:
https://gitlab.com/lilypond/lilypond/-/merge_requests/251
On Wed, Jul 1, 2020 at 2:03 PM Jean Abou Samra wrote:
> The Contributor's Guide (10.5.1) clearly states that "Python code should
> use PEP 8". So, I'd like to be sure everyone agrees on the following points
> which are part of applying this PEP:
to me it's a no-brainer to introduce automatic form
For automatic PEP8 formatting, there is
autopep8: https://pypi.org/project/autopep8/ and
yapf: https://pypi.org/project/yapf/
among others.
Cheers,
Joram
On Wed, Jul 1, 2020 at 10:55 AM Jean Abou Samra wrote:
> Hi Carl,
>
> Thanks for your reply.
> Le 01/07/2020 à 17:05, Carl Sorensen a écrit :
>
> Hi Jean,
>
> On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote:
>
>> Hi everybody,
>>
>> There
Hi Carl,
Thanks for your reply.
Le 01/07/2020 à 17:05, Carl Sorensen a écrit :
Hi Jean,
On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra <mailto:j...@abou-samra.fr>> wrote:
Hi everybody,
There is some discussion in !212 about coding style inside our Python
scripts.
Hi Jean,
On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote:
> Hi everybody,
>
> There is some discussion in !212 about coding style inside our Python
> scripts.
>
> The Contributor's Guide (10.5.1) clearly states that "Python code should
> use PEP 8". So,
Hi everybody,
There is some discussion in !212 about coding style inside our Python
scripts.
The Contributor's Guide (10.5.1) clearly states that "Python code should
use PEP 8". So, I'd like to be sure everyone agrees on the following points
which are part of applying
t and as such it had to be approved
manually?
> The song is in Danish and I'd like the chords to be rendered in the
> traditional Danish style. I don't know if this is Danish only (could be
> Scandinavian?)
If you can investigate, that would be great. Alternatively, could you
el
ditional Danish style. I don't know if this is Danish only (could be
Scandinavian?), but I'll just refer to it as D-style. In any case, it
doesn't seem to be supported by lilypond. So I took a look at the source
and found a way to make it render (almost) like I want it.
The "D-
Hi there.
I recently stumbled upon this great project and thought I'd use it to
render the score of a little melody with chords and lyrics.
The song is in Danish and I'd like the to be rendered in the traditional
Danish style. I don't know if this is Danish only (could be Scan
:08, Dan Eble wrote:
> This is not an issue with this change, but should this function do
something
> other than divide by zero when springs is empty?
what is the average of an empty set of numbers?
the 2 callers use a fallback in case there are not springs.
Description:
Cast to Real in C++
On 2020/02/02 18:51:08, Dan Eble wrote:
> LGTM
>
> https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
> File lily/spring.cc (right):
>
>
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
> lily/spring.cc:119: avg_stretch /= static_cast (springs.
LGTM
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
File lily/spring.cc (right):
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
lily/spring.cc:119: avg_stretch /= static_cast (springs.size ());
This is not an issue with this change, but
Urs Liska writes:
> Am Freitag, den 31.01.2020, 18:38 +0100 schrieb:
>> Urs Liska writes:
>>
>> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
>> > > On 2020/01/29 12:20:10, mail5 wrote:
>> > > > Unfortunately I haven't set up a build system on my new
>> > > > computer
>> > >
Am Freitag, den 31.01.2020, 18:38 +0100 schrieb David Kastrup:
> Urs Liska writes:
>
> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
> > > On 2020/01/29 12:20:10, mail5 wrote:
> > > > Unfortunately I haven't set up a build system on my new
> > > > computer
> > > > yet,
> > > so
Urs Liska writes:
> Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
>> On 2020/01/29 12:20:10, mail5 wrote:
>> > Unfortunately I haven't set up a build system on my new computer
>> > yet,
>> so this
>> > patch is not tested locally at all, so I'm humbly waiting for the
>> automated
On Wed, Jan 29, 2020 at 4:02 PM wrote:
>
> On 2020/01/29 12:20:10, mail5 wrote:
> > Unfortunately I haven't set up a build system on my new computer yet,
> so this
> > patch is not tested locally at all, so I'm humbly waiting for the
> automated
> > tests to succeed or fail ...
>
> I don't like th
Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
> On 2020/01/29 12:20:10, mail5 wrote:
> > Unfortunately I haven't set up a build system on my new computer
> > yet,
> so this
> > patch is not tested locally at all, so I'm humbly waiting for the
> automated
> > tests to succeed or fai
On 2020/01/29 12:20:10, mail5 wrote:
> Unfortunately I haven't set up a build system on my new computer yet,
so this
> patch is not tested locally at all, so I'm humbly waiting for the
automated
> tests to succeed or fail ...
I don't like the "use-modules clauses adjusted accordingly". I don't
th
Reviewers: ,
Message:
Unfortunately I haven't set up a build system on my new computer yet, so
this patch is not tested locally at all, so I'm humbly waiting for the
automated tests to succeed or fail ...
Description:
Move Guile-style modules from scm to scm-modules
As an initial step
Thanks Hans!
JM
> Le 11 juil. 2019 à 18:01, Hans Åberg a écrit :
>
>
>> On 11 Jul 2019, at 09:32, Jacques Menu wrote:
>>
>> I’ve wondering about command line options with multiple values.
>>
>> Which one of the following in preferable in your opinion:
>>
>> DESSUS="Cor anglais"
>> xml2ly -
> On 11 Jul 2019, at 09:32, Jacques Menu wrote:
>
> I’ve wondering about command line options with multiple values.
>
> Which one of the following in preferable in your opinion:
>
> DESSUS="Cor anglais"
> xml2ly -msr-part-rename "P1 = ${DESSUS}"
>
> or:
>
> DESSUS="Cor anglais"
> xml2ly -ms
Hello folks,
I’ve wondering about command line options with multiple values.
Which one of the following in preferable in your opinion:
DESSUS="Cor anglais"
xml2ly -msr-part-rename "P1 = ${DESSUS}"
or:
DESSUS="Cor anglais"
xml2ly -msr-part-rename P1 "${DESSUS}"
Thanks for your advice!
JM
overall style of the Feta font.
You're probably right.
I am a little confused as to my eye-sight - even after I checked that
the glyph is completely symmetric, I "feel" that the \haydnturn's right
part is "steeper". At one point I thought it might be an optical
il
On 2018/04/10 17:21:43, Malte Meyn wrote:
make slashturn 4% thinner at the center (instead of 10% thicker)
IMHO that’s an improvement.
haydnturn 0%
thicker (instead of 10% thicker)
I’m not sure whether this is, the glyph shouldn’t be too slim to match
the overall style of the Feta font
On 2018/04/10 09:47:31, Lukas-Fabian Moser wrote:
This is gorgeous! Thanks very much!
Is the \haydnturn supposed to be symmetrical w.r.t. the stem? To me it
looks as
if it weighs slightly more on the left, but maybe I'm wrong? (And I'm
also not
sure if this would be a problem if I were rig
This is gorgeous! Thanks very much!
Is the \haydnturn supposed to be symmetrical w.r.t. the stem? To me it
looks as if it weighs slightly more on the left, but maybe I'm wrong?
(And I'm also not sure if this would be a problem if I were right.)
(The Henle score that prompted me to ask in the fir
se scripts are semantically distinct or just stylistically
distinct.
How would one make a single command that can use both styles? Maybe
something like
\override Script.haydnturn-style = #'turn % default #'wiggle
?
It sounds like you're saying we don't know if they are semanti
On 2018/04/08 17:43:36, simon.albrecht wrote:
I’m not sure what exactly the difference in performing is, but that’s
not for us to consider; it’s important for scholarly editing (of
mid-to-late 18th century music, especially Haydn) to have this symbol
available.
Having two symbols available does
On 2018/04/08 17:08:42, Dan Eble wrote:
Is there a performance difference between these two scripts? I read
quickly
through the thread referenced in the ticket, but I couldn't find the
answer.
I don’t know; I’m not even sure whether \haydnturn should be played as
\mordent or as \turn. The 19
On 08.04.2018 19:08, nine.fierce.ball...@gmail.com wrote:
Is there a performance difference between these two scripts? I read
quickly through the thread referenced in the ticket, but I couldn't find
the answer.
I’m not sure what exactly the difference in performing is, but that’s
not for us
Is there a performance difference between these two scripts? I read
quickly through the thread referenced in the ticket, but I couldn't find
the answer.
https://codereview.appspot.com/340660043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Very nice! LGTM.
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf#newcode757
mf/feta-scripts.mf:757: set_char_box (wd# / 2, wd# / 2, ht# / 2 *
height_factor, ht# / 2 * height_f
Reviewers: Malte Meyn,
Message:
On 2018/02/07 07:41:09, Malte Meyn wrote:
“Make […] work for *me*” sounds as if this isn’t a general problem? I
don’t know
*anything* about emacs (except that vim is superior :P) but googling
c-default-style makes me wonder whether this isn’t only a problem of
“Make […] work for *me*” sounds as if this isn’t a general problem? I
don’t know *anything* about emacs (except that vim is superior :P) but
googling c-default-style makes me wonder whether this isn’t only a
problem of your emacs config.
Is it possible that this patch breaks the behaviour for
LGTM
https://codereview.appspot.com/340140043/diff/1/Documentation/included/gsoc.itexi
File Documentation/included/gsoc.itexi (right):
https://codereview.appspot.com/340140043/diff/1/Documentation/included/gsoc.itexi#newcode172
Documentation/included/gsoc.itexi:172: (this would involve working
Reviewers: ,
Message:
Please review
Description:
Issue 4983 Let crossStaff hide non-default-style flags
Return empty-stencil for all flags using the code provided in
flag-styles.scm, if the style property is 'no-flag as set by
the crossStaff-function.
Please review this at
LGTM
https://codereview.appspot.com/311430043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set is online that includes an entry in changes.tely and
changes the wording of the two places in question.
Cheers,
Alexander
https://codereview.appspot.com/311430043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu
Alexander, you wrote Thursday, December 15, 2016 3:51 PM
> On 2016-12-15 13:34, Trevor Daniels wrote:
>
>> Adding you to the dev list is very little work, but you do have to
>> get a SourceForge id and tell me what it is for me to do that.
>>
>> James probably is willing to undertake the work of
On 2016-12-15 13:34, Trevor Daniels wrote:
Alexander, you wrote Wednesday, December 14, 2016 11:49 PM
yes, I guess I never asked to be on that list. My last commit was
pre-Rietveld and pre-Allura, I think; and it's unlikely that
contributions from my side will come more often in the foreseeable
2016-12-14 13:15, James wrote:
>>>
>>>> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
>>>>> Reviewers: ,
>>>>>
>>>>> Message:
>>>>> add choral and choral-cautionary accidental style
>>>> ...
>>&g
ristics of modern-voice and piano or their equivalents with
cautionary accidentals."
Some wording-nitpicks, otherwise
LGTM
Thanks.
https://codereview.appspot.com/311430043/diff/1/Documentation/notation/pitches.itely#newcode2210
Documentation/notation/pitches.itely:2210: style. It is intend
Trevor Daniels wrote:
Alexander, you wrote Wednesday, December 14, 2016 12:32 PM
On 2016-12-14 13:15, James wrote:
On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
Reviewers: ,
Message:
add choral and choral-cautionary accidental style
...
Please review this at https://codereview.a
#newcode2210
Documentation/notation/pitches.itely:2210: style. It is intended for
editions that are used both by singers that only
The wording feels not very elegant.
Though, I'm a non-native speaker...
https://codereview.appspot.com/311430043/diff/1/scm/music-functions.scm
File scm/music-function
Alexander, you wrote Wednesday, December 14, 2016 12:32 PM
> On 2016-12-14 13:15, James wrote:
>
>> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
>>> Reviewers: ,
>>>
>>> Message:
>>> add choral and choral-cautionary accidental
Passes make, make check and a full make doc
https://codereview.appspot.com/311430043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 14/12/16 12:32, Alexander Kobel wrote:
Hi James,
thanks for taking care of that one.
On 2016-12-14 13:15, James wrote:
Hello,
On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
Reviewers: ,
Message:
add choral and choral-cautionary accidental style
...
Please review this at
Hi James,
thanks for taking care of that one.
On 2016-12-14 13:15, James wrote:
Hello,
On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
Reviewers: ,
Message:
add choral and choral-cautionary accidental style
...
Please review this at https://codereview.appspot.com/311430043
Hello,
On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
Reviewers: ,
Message:
add choral and choral-cautionary accidental style
...
Please review this at https://codereview.appspot.com/311430043/
Affected files (+151, -1 lines):
M Documentation/notation/pitches.itely
M ly
Reviewers: ,
Message:
add choral and choral-cautionary accidental style
This solves the issues mentioned in
https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00201.html
that accidental style could not apply to ChoirStaves in the same way as
they did for PianoStaves, StaffGroups or
On 2015/11/26 16:29:59, Trevor Daniels wrote:
LGTM
When this is pushed we ought to raise an issue to document whiteout
properly in
the NR.
https://sourceforge.net/p/testlilyissues/issues/4681/
James
https://codereview.appspot.com/274590043/
__
LGTM
When this is pushed we ought to raise an issue to document whiteout
properly in the NR.
https://codereview.appspot.com/274590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Please review, thanks,
-Paul
Description:
Implement rounded-box whiteout style
As suggested in issue 4504.
Includes edits to regression tests and
changes entry.
Please review this at https://codereview.appspot.com/274590043/
Affected files (+65, -25 lines):
M
Hi Simon,
> On Oct 25, 2015, at 6:02 PM, Simon Albrecht wrote:
>
> I think this is not the best possible setting: If I want to apply
> whiteout-outline now, I have to use two overrides. IMO it would be easier to
> use if we had the two properties
> – whiteout [possibly whi
Hello Paul,
On 25.10.2015 20:39, Paul Morris wrote:
Introduce whiteout-style, with options of
'box and 'outline, as a grob property to be
used with the whiteout grob property, and as
an optional property of the whiteout markup
command.
Remove the whiteou
Greetings LilyPond devs,
I’m attaching patches for review for issue 4504 – implementing the
whiteout-style approach instead of separate whiteout and whiteout-box commands.
I tried to upload to Rietveld using Phil's new git-cl (from Federico's new
LilyDev4) but so far no luck. So
On 5/29/15 4:00 PM, "David Kastrup" wrote:
>I also don't quite get what "it never got officially adopted" means in
>light of commits like
>
>commit cf137655b7aee9988ef536d6fa5e38d279ee73cf
>Author: David Kastrup
>Date: Mon Jun 10 17:28:51 2013 +0200
>
>Run scripts/auxiliar/fixscm.sh scm/
Carl Sorensen writes:
> On 5/29/15 1:25 PM, "Simon Albrecht" wrote:
>
>>Hello,
>>
>>a while ago I found this document on what appear to be very widely
>>accepted standards for formatting scheme code:
>><http://community.schemewiki.org/?scheme-s
to be very widely
accepted
standards for formatting scheme code:
<http://community.schemewiki.org/?scheme-style>. I find it very useful
and
it seems to be altogether uncontroversial while warranting good
legibility.
Do we also accept these guidelines in our use of scheme? If yes, we
should
cons
Am 29.05.2015 um 22:25 schrieb Carl Sorensen:
On 5/29/15 1:25 PM, "Simon Albrecht" wrote:
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
<http://community.schemewiki.org/?scheme-style>. I find it ve
On 5/29/15 2:30 PM, "Thomas Morley" wrote:
>2015-05-29 21:25 GMT+02:00 Simon Albrecht :
>> Hello,
>>
>> a while ago I found this document on what appear to be very widely
>>accepted
>> standards for formatting scheme code:
>> <http://community.
Am 29.05.2015 um 22:30 schrieb Thomas Morley:
2015-05-29 21:25 GMT+02:00 Simon Albrecht :
Hello,
a while ago I found this document on what appear to be very widely accepted
standards for formatting scheme code:
<http://community.schemewiki.org/?scheme-style>. I find it very useful and
it
2015-05-29 21:25 GMT+02:00 Simon Albrecht :
> Hello,
>
> a while ago I found this document on what appear to be very widely accepted
> standards for formatting scheme code:
> <http://community.schemewiki.org/?scheme-style>. I find it very useful and
> it seems to be al
On 5/29/15 1:25 PM, "Simon Albrecht" wrote:
>Hello,
>
>a while ago I found this document on what appear to be very widely
>accepted standards for formatting scheme code:
><http://community.schemewiki.org/?scheme-style>. I find it very useful
>and it seems to b
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
<http://community.schemewiki.org/?scheme-style>. I find it very useful
and it seems to be altogether uncontroversial while warranting good
legibility.
Do we also
Thomas Morley writes:
> 2015-04-08 12:04 GMT+02:00 David Kastrup :
[...]
>>> (display (eqv? -1 DOUBLE-FLAT))
>>> -> #t
>>>
>>> (display
>>> (case -1
>>>((DOUBLE-FLAT) "--")
>>>((FLAT) "-")
>>>((NATURAL) "")
>>>((SHARP) "+")
>>>((DOUBLE-SHARP) "++")))
>>> -> #
>> That one's
cluded/chord-names-jazz.ly with uncommented
>>> Banter-style is broken.
>>> At least since 2.12.3
>>>
>>> The problem is in 'step->markup-plusminus'
>>>
>>> Here you see the old code commented and a possible patch inserted:
>&g
Thomas Morley writes:
> 2015-04-08 11:45 GMT+02:00 Thomas Morley :
>
>> I started to rewrite chord-namings and stumbled over a problem in
>> chord-generic-names.ly
>>
>> /Documentation/included/chord-names-jazz.ly with uncommented
>> Banter-style is broken
2015-04-08 11:45 GMT+02:00 Thomas Morley :
> Hi.
>
> I started to rewrite chord-namings and stumbled over a problem in
> chord-generic-names.ly
>
> /Documentation/included/chord-names-jazz.ly with uncommented
> Banter-style is broken.
> At least since 2.12.3
>
> T
1 - 100 of 423 matches
Mail list logo
