Am 20.07.2014 11:10, schrieb Janek Warchoł:
Hi folks,
as you can see, i'm falling behind with lilypond stuff, but i wanted
to let you know that i've skimmed through this discussion and it LGTM.
The only comment i have is: try to make things as simple as possible
(but not simpler, of course) - i
Hi folks,
as you can see, i'm falling behind with lilypond stuff, but i wanted
to let you know that i've skimmed through this discussion and it LGTM.
The only comment i have is: try to make things as simple as possible
(but not simpler, of course) - i wouldn't like openlilylib getting a
"java-smel
Am 07.07.2014 16:48, schrieb Paul Morris:
Urs Liska wrote
>Hm, I think I_must not_ start with such a script right now, since I
>know that this - although being not too complex - will eat up too much
>of my time and concentration.
>
>But your message triggered a little bit of thought, and I came
On 7. Juli 2014 16:48:44 MESZ, Paul Morris wrote:
>Uns Liska wrote
>> Hm, I think I _must not_ start with such a script right now, since I
>> know that this - although being not too complex - will eat up too
>much
>> of my time and concentration.
>>
>> But your message triggered a little bit
Uns Liska wrote
> Hm, I think I _must not_ start with such a script right now, since I
> know that this - although being not too complex - will eat up too much
> of my time and concentration.
>
> But your message triggered a little bit of thought, and I came to the
> conclusion that we should u
Am 07.07.2014 12:01, schrieb Jan-Peter Voigt:
Am 07.07.2014 11:46, schrieb Urs Liska:
I followed the discussion only roughly, but I think it is a step in the
right direction. I'd like to bring up the scheme-modules, I came up
with. They need a fixed folder-structure and need to be updated
accord
Am 07.07.2014 11:46, schrieb Urs Liska:
>> I followed the discussion only roughly, but I think it is a step in the
>> right direction. I'd like to bring up the scheme-modules, I came up
>> with. They need a fixed folder-structure and need to be updated
>> according to the path they are stored in.
>
Am 07.07.2014 11:37, schrieb Jan-Peter Voigt:
Hi Urs and all,
I followed the discussion only roughly, but I think it is a step in the
right direction. I'd like to bring up the scheme-modules, I came up
with. They need a fixed folder-structure and need to be updated
according to the path they are
Hi Urs and all,
I followed the discussion only roughly, but I think it is a step in the
right direction. I'd like to bring up the scheme-modules, I came up
with. They need a fixed folder-structure and need to be updated
according to the path they are stored in.
Should we have a dedicated folder fo
Am 07.07.2014 10:37, schrieb Urs Liska:
Am 07.07.2014 09:55, schrieb Urs Liska:
Maybe we can have a compromise. A script parsing the content of the tags
field from all files shouldn't be hard to write. So we could:
- agree upon an initial set of categories
- agree upon a naming convention for ta
Am 07.07.2014 09:55, schrieb Urs Liska:
Maybe we can have a compromise. A script parsing the content of the tags
field from all files shouldn't be hard to write. So we could:
- agree upon an initial set of categories
- agree upon a naming convention for tags
(e.g. the same dashed-lowercase-sch
Am 06.07.2014 17:15, schrieb Paul Morris:
Uns Liska wrote
Starting by tagging the existing snippets sounds fine to me.
But not tagging directly but collecting suggestions first. Then decide
about a set of tags and apply them during the move.
Ok, sure.
Something to consider: since you are pl
Uns Liska wrote
>>Starting by tagging the existing snippets sounds fine to me.
>
> But not tagging directly but collecting suggestions first. Then decide
> about a set of tags and apply them during the move.
Ok, sure.
Something to consider: since you are planning on writing a script to walk
thro
On 6. Juli 2014 16:12:56 MESZ, Paul Morris wrote:
>Uns Liska wrote
>> Some of them are good, some of them less so, I think.
>> Maybe we could start going through the existing snippets and consider
>
>> possible tags for each of them. This will make a pool of suggestions
>> where we can filter o
Uns Liska wrote
> Some of them are good, some of them less so, I think.
> Maybe we could start going through the existing snippets and consider
> possible tags for each of them. This will make a pool of suggestions
> where we can filter out from.
>
> One question I still have is: Should the tags
Am 05.07.2014 18:22, schrieb Paul Morris:
Uns Liska wrote
I have updated the Wiki page
https://github.com/openlilylib/openlilylib/wiki
and added a note about the reorganization process in the README.md on
the restructuring branch.
It's looking good to me. From the wiki page:
"Probably it's
Uns Liska wrote
> I have updated the Wiki page
> https://github.com/openlilylib/openlilylib/wiki
>
> and added a note about the reorganization process in the README.md on
> the restructuring branch.
It's looking good to me. From the wiki page:
"Probably it's a good idea to assign a primary tag
Am 05.07.2014 10:31, schrieb Urs Liska:
Thanks.
I think we will have to reconsider our metadata section and then do the
transfer in that "reorganization" branch. I strongly suggest to
excusively do that using pull requests, even among the members with push
access.
One more thing I would suggest
Am 05.07.2014 05:30, schrieb Paul Morris:
Uns Liska wrote
I can see the point and I'm ready to accept that approach. There is one
issue, however, that I'd like to discuss before making any decision.
\include "file-name.ily"
opens the door wide for name conflicts. The more the names are s
Uns Liska wrote
> I can see the point and I'm ready to accept that approach. There is one
> issue, however, that I'd like to discuss before making any decision.
>
> \include "file-name.ily"
>
> opens the door wide for name conflicts. The more the names are speaking
> the more they will be
Am 04.07.2014 17:14, schrieb Paul Morris:
Uns Liska wrote
Am 03.07.2014 19:50, schrieb Paul Morris:
Hi Urs, This is looking like an improvement to me. Here's a thought.
If
the emphasis is on include-ability, what about just having all the
include
files at the same level in the "Library" direc
2014-07-04 17:14 GMT+02:00 Paul Morris :
> One nice thing about decoupling the actual location of the files (their
> include path) from the categories/tags/navigation structure, is that you
> can
> change the latter as needed as the library changes and matures, without
> breaking compatibility wit
Uns Liska wrote
> Am 03.07.2014 19:50, schrieb Paul Morris:
>> Hi Urs, This is looking like an improvement to me. Here's a thought.
>> If
>> the emphasis is on include-ability, what about just having all the
>> include
>> files at the same level in the "Library" directory, without needing to
>>
2014-07-03 17:51 GMT+02:00 Noeck :
> I'd like to second especially the renaming/reodering of the
> definitions file. It looks better without definition(s).ily at the end.
>
Me too, speaking file names are much better
___
lilypond-user mailing list
lilyp
2014-07-04 12:23 GMT+02:00 Urs Liska :
>- I don't see yet what would go into »specific instruments/repertoire«
>>
>
> For example shortcuts for staff changes in piano music.
> Snippets for specific bending techniques for guitar.
> Lute tablature.
This way the bending techniques for guitar wo
Am 03.07.2014 17:51, schrieb Noeck:
Hi,
I like your ideas on the wiki.
- I'd like to second especially the renaming/reodering of the
definitions file. It looks better without definition(s).ily at the end.
However, it means that the content of the library doubles (one folder
and one ily).
I am n
Sounds interesting, but I don't thing the time is ready for that. There
has been discussion of providing a structure similar to the "TEXMF" tree
in LaTeX distributions. This would be a place where "library" additions
or "packages" could be stored to and made available in the official
LilyPond d
Am 03.07.2014 19:50, schrieb Paul Morris:
Uns Liska wrote
I think that after an initial phase of trial & error we should
now do it right and create a structure we can live with for the future.
Hi Urs, This is looking like an improvement to me. Here's a thought. If
the emphasis is on include
On Thu, Jul 3, 2014 at 1:06 AM, Urs Liska wrote:
> Our repository has now lived for some time, and I think it is a good thing
> to have and maintain. The recent renaming was partially intended to stress
> its nature as an _includable_ library (as opposed to the official LSR). But
> to make that wo
Uns Liska wrote
> I think that after an initial phase of trial & error we should
> now do it right and create a structure we can live with for the future.
Hi Urs, This is looking like an improvement to me. Here's a thought. If
the emphasis is on include-ability, what about just having all the
Hi,
I like your ideas on the wiki.
- I'd like to second especially the renaming/reodering of the
definitions file. It looks better without definition(s).ily at the end.
However, it means that the content of the library doubles (one folder
and one ily).
I am not sure, if it is a good idea, but the
31 matches
Mail list logo
