before \hspace #0 and once
behind it.
--
David Kastrup
e
experienced people desiring to bunch their work before testing, the
triggering could also happen manually by whoever thinks he has pushed
enough stuff to staging to give it a whirl.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
>> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote:
>> > > >
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> > > The "traffic jam" problem could be avoided by retaining
Jonas Hahnfeld writes:
> Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld writes:
>> > > > Am Donnerstag, den
ower by a
> factor of 2, I'd call that a regression in general.
If it is by the translation team doubling the number of supported
languages... Actually, if translations were all kept up to date, we'd
probably need less time for "make doc" since then most of the
translations would work with the same code examples.
--
David Kastrup
e likely in a capacity of
interpreting the respective traces of Bison.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> We have a dump of the bison grammar in the contributor guide (see
>> http://lilypond.org/doc/v2.19/Documentation/contributor/lilypond-grammar).
>>
>> Is there any value in keeping this? It complicates the g
figure out how to track this. I think our
> runners are prioritized, but this should become clear soon.
I think configure options should likely point to Guile-1.8 (for now) and
use --enable-checking and (to save CI minutes) --enable-gs-api .
Reasonable?
--
David Kastrup
Han-Wen Nienhuys writes:
> thanks, I'll take this as an OK to drop grammar from the manual.
I am actually unhappier about seeing the mechanism for generating it
disappear rather than the grammar itself. But for LilyPond, it really
does no longer provide a reasonable value.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 10:18 +0200 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 24.05.2020, 00:21 +0200 schrieb David Kastrup:
>> > I think configure options should likely point to Guile-1.8 (for now) and
>> > use --enable-checking and (to s
e submitter to not follow up with
an actual merge.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 16:28 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
>> > > So, and you didn't answer this specific question, if I set the label to
ly manual (with "merge when pipeline succeeds"
> being automatic). This has been clearly communicated, sorry if you
> missed that.
Well, the point of a working mechanism is that nothing needs to get
communicated by side channels. Of course, we aren't there yet since we
are still figuring out our usage patterns for Gitlab.
> Jonas
>
--
David Kastrup
Dan Eble writes:
> On May 27, 2020, at 07:16, David Kastrup wrote:
>>
>> Now that we have the first "please get in line" merge that isn't
>> actually to any degree unusual, I get the suspicion that my previous
>> alternative proposal of pushing to a C
venue (-user list, -devel, bugtracker,
> code reviewing, doc editing or merge requests) and, personally
> speaking, the more we see of you the better. But of course, that’s
> entirely up to you and may vary from time to time depending on your
> free time and motivation; these are, after all, the only two
> ingredients Free Software is made of.
--
David Kastrup
mean that you can usually rebase and forget without waiting
for pipeline completions. And you get the liberty of bypassing most CI
and rebases if you don't want to.
I may be wrong about the possibility to do this with a reasonable amount
of effort: I don't want to get hopes up unnecessarily.
--
David Kastrup
, the tool being standard or not.
But I agree that a custom GUI tool is likely not helpful. Not least of
all since it just isn't a useful resource for people who actually
already have their own rapport working with Git, and those are a
significant part of the developer base.
--
David Kastrup
> so I could submit 7 MRs in one go. This worked satisfactorily for me,
> so I retract my criticism.
It's a manually done technique, and will still lead to competing
pipelines from different users.
--
David Kastrup
quency of build system changes, it seems like
any such change should be done in a manner where it does not require
more than the flip of a switch to change back temporarily.
--
David Kastrup
ith your GCC 10 problem: I don't remember anything related to that. If
it doesn't, you might want to ask Thien-Thi Nguyen (who has made this
branch tip work so far) to take a look.
--
David Kastrup
from the
> recursive call which the check relies on. Funnily enough, a comment
> says: "If the code could be inlined, that might cause the test to give
> an incorrect answer." - indeed.)
It's easy enough to write a recursive call that cannot be tail-call
optimised. It may be old code, but it was trouble waiting to happen.
--
David Kastrup
getting fresh warnings _reported_ for changes seems like a
good idea. Making it a no-go to have them, however, seems too
restrictive to me.
--
David Kastrup
/?id=aa18f519e091b6ada0fb2b0a65a51880031d5014
Uh oh. This looks like it introduces (modifies?) a command named
@seealso but it would appear that we define our own version of it.
--
David Kastrup
i`
> files.
>
> David, would you do that and fast-track this mechanical change?
We don't use camelcase elsewhere in Texinfo.
@morerefs
maybe?
--
David Kastrup
i`
> files.
>
> David, would you do that and fast-track this mechanical change?
No idea what makes me the go-to here, but anyway.
<https://gitlab.com/lilypond/lilypond/-/merge_requests/173>
--
David Kastrup
ay where that comes from.
>
> No, this is the only smallest possible EPS file that shows the problem.
> I'm attaching the real file from LilyPond to this message, but the
> important part is probably that it contains no graphical objects.
That triggers some memory: this may not have anything to do with
autorotation? That GhostScript decides on landscape orientation
unexpectedly or so?
--
David Kastrup
ts. Returning it to
the _Scheme_ layer should never be done.
For functions not returning a specific value, return SCM_UNSPECIFIED; is
the right course.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Jun 19, 2020 at 3:13 PM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>> >> No changes for me. Please also keep in mind that the same command
>
; is kind of the extended C++ STL).
Not that I know of.
--
David Kastrup
of 'Verified' but for newly entered issues.
>
> A LP developer who created an issue with a patch/fix would simply jump
> to 'started'.
>
> This was something else that a 'non-developer' could contribute to the
> LP project so developers could get on with fixing issues.
>
> Regards
>
> James
>
>
>
>
>
--
David Kastrup
f in deval (x=0x7f01bed86010, x@entry=0x7f01bed818a0,
> env=0x7f01b13c9130, env@entry=0x7f01b13c92c0) at eval.c:3469
> #16 0x7f01cbb4bba4 in scm_dapply (proc=0x7f01beb47ff0, arg1= out>, args=0x7f01b13c92c0) at eval.c:5012
> #17 0x7f01c1096c1a in scm_srfi1_map (proc=0x7f01b13c9b70,
> arg1=0x7f01b13c9be0, args=) at srfi-1.c:1443
Huh. Maybe the file is renamed before Guile lets go of it? Or it may
be a buffer overflow in Guile's input handling.
--
David Kastrup
hed to say that the beginner's mistake would have been
running something with a registry as host system, but then with the
advent of systemd as a Linux system component, the comparison has become
lots murkier. Managing conflicts has become black magic. Linux tends
to work more reliable magic, but either way there is too much happening
behind the scenes.
--
David Kastrup
classes and context () for others. Or
get_parent_context () for some and get_daddy_context () for others.
Generally the get_ prefix seems a bit spurious: given that we use the
naming convention field_ for data members, calling the read accessor
field () seems like it should always be workable.
--
David Kastrup
I think that my original
> idea was to just produce the html, while the person(s) who wanted
> to have all docs available offline where you, Jan, John Mandereau,
> and/or David Kastrup. (It was definitely an emacs user!)
I am frequently using the Info files to look up stuff in the index
an
way, when not using
merge_request.title, the title is just picked off the headline of the
commit) to the same branch. Since you likely have amended your commit
instead of adding one on top, this will not be a fast forward push, so
you'll need the -f option or use +HEAD:my-proposed-branch-name as
source:target description. It's the same requirement as you'd have
after rebasing.
--
David Kastrup
Thomas Morley writes:
> Am Mi., 15. Juli 2020 um 00:15 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Am Di., 14. Juli 2020 um 22:14 Uhr schrieb Thomas Morley
>> > :
>> >>
>> >> Am Di., 14. Juli 2020 um 22:03 Uhr s
reate-file-exclusive which returns #f if the file already exists
> (or could not be created).
I had commented on the respective issue without response that the
parallel processes, without taking additional measures, will generate
the same "random" sequence, making this no better than ju
Jonas Hahnfeld writes:
> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes:
>> > > Here's the logfile and the ly file.
>> >
>> > Could
David Kastrup writes:
> Jonas Hahnfeld writes:
>
>> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup:
>>> Jonas Hahnfeld writes:
>>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes:
>>> > > Here's the logfile a
Han-Wen Nienhuys writes:
> On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote:
>
>> Well ok. But only 100 random numbers are being used (there is
>> another call using 1000 instead, the choice appearing random).
>> Let's assume we have 10 processes going
-lilypond.git-release-unstable'
>
> And that's where it stops doing anything.
>
> Anyone any ideas?
Sounds like tar (or some other program?) got nonsensical options and is
now waiting for input from the terminal instead of some program or file.
You can try to see what happe
s-tube. One case
where unfortunately someone who does not know history is not bound to
repeat it.
--
David Kastrup
> I'm not…”.
>
> Hope humor helps things progress,
> Jean
Frankly, never mind the Latin. I get the shakes when many native
English speakers try their hands at Early Modern English, the variant
often used by Shakespeare and also typical for the KJV Bible
translation, and completely mess up things like speaketh, speakest,
thou, thee, thine; basically picking between older forms randomly.
--
David Kastrup
orrection, and
the result does not work.
> \override Score.NoteHead.output-attributes.id = #'((id . "foo"))
>
> I get the error:
>
> Unsupported SCM value for format: ((id . foo))
Because you set output-attributes to ((id . ((id . "foo" rather than
to ((i
ill make them
unusable.
I'm not saying that those two reasons should be enough, just mention
them for consideration. I find the former more useful than the latter,
but then I do use Emacs as Info reader.
--
David Kastrup
rrect. I may change that eventually, but that's basically a
possibility at the bottom of a stack of rather extensive purportive
changes, so don't hold your breath for it.
--
David Kastrup
Jean Abou Samra writes:
> Le 6 août 2020 à 12:21, David Kastrup < d...@gnu.org> a écrit :
>
> Changing
>
> \override NoteHead.id = #note-id
>
> to
>
> \override Score.NoteHead.output-attributes.id = #note-id
>
> only works if note-id
le moniker. The stable branch tends to
see only rather superficial testing, and a large divergence from master
would make its stability more a matter of wishful thinking than release
engineering.
--
David Kastrup
release would
be "outdated from the start" with regard to some "must-have" features
that would be expected to be common in suggested code on the mailing
lists.
So 2.20's history in some way reflects how to muddle through in a
situation that became a lot different from planning. It's not really a
template for how things should work.
--
David Kastrup
h moderate success.
However, as release stoppers were accumulating and the release process
got stuck up, the "don't do development" appeals stopped making a whole
lot of sense.
> Just trying to understand what might have worked in the past...
I sure wished I had been able to get an understanding about what might
have worked...
--
David Kastrup
e like
\repeat volta 40 {
...
\alternative { ... }
\alternative { ... }
\alternative { ... }
}
since that would avoid several syntactical problems and would allow to
produce alternatives by music functions.
So if we are going to start phantasizing, that would be an approach I'd
prefer to start out from.
--
David Kastrup
Dan Eble writes:
> On Aug 29, 2020, at 14:52, David Kastrup wrote:
>>
>> My own take on it is that \alternative syntax is an abomination and it
>> should likely be more like
>>
>> \repeat volta 40 {
>> ...
>> \alternative { ..
al_ number list if we are
reasonably sure that this is all we need.
Usually prettier alternatives can come with a backward compatibility
hook (though their lifetime tends to be semi-eternal). But in this case
the ugliness does not just extend to the input, but also to the input
processing.
--
David Kastrup
uld be interpretted as: the 1st, 2nd, and 4th endings are c,
> and the 3nd ending is d.
That is already valid syntax and makes the first and second alternative
c1 and the third and fourth alternative d1 .
Extending LilyPond syntax is not really a matter of arbitrarily
inventing something: a lo
0"
\version "2.6.0"
\version "2.6.0"
\version "2.6.2"
\version "2.6.3"
\version "2.6.3"
\version "2.6.3" % necessary for upgrading to future LilyPond versions.
\version "2.6.4"
\version "2.6.4"
\version "2.6.4"
and so on. Stuff like that will not likely convert nicely, but at least
having a start seems like common courtesy.
--
David Kastrup
Christopher Heckman writes:
> On Sun, Aug 30, 2020 at 11:59 AM David Kastrup wrote:
>>
>> Christopher Heckman writes:
>>
>> > How about allowing modifying the syntax of \alternative to include the
>> > possibility of a number, which means to repeat
sort of freeze
> 3) Branch off stable/2.22 and cherry-pick only fixes
I think that "some sort of freeze" makes sense only in light of defining
goals to achieve for the next stable release. As long as those goals
still necessitate disruptive/extensive changes, there is not much of a
point in branching.
--
David Kastrup
think about this? Having a
> large silent mass is not really helpful for this kind of discussion (as
> it wasn't for the switch to GitLab).
Frankly I don't see the point in repeating points I already made and
call that "discussion".
I don't see that in the current stage of upheaval of both internals and
build system and infrastructure, there is a point in freezing off some
half-baked intermediate state that hasn't seen significant exposure to
extensive testing.
--
David Kastrup
nd.
>
> I see the value of faster builds, but I think being correct is more
> important than being fast.
>
> What annoys me is that the default build creates the info docs, which
> aren't necessary for developing lilypond.
This checks, for example, music function comments for correct Texinfo
syntax (even if it does not test embedded LilyPond for validity).
--
David Kastrup
language selection; afterwards
all links should stick with the selected language.
Of course the problem with that is that this should not be the case for
an English-language fallback. Strictly speaking, those should not be
the same as the normal English-language pages but rather be per-language
co
occurs _after_ the general
start-translation-timestep phase. For _explicitly_ instantiated
contexts (like \new Voice ...) I think it is being called.
No guarantees, but that's the way I remember.
--
David Kastrup
chieve some leverage. I doubt that they
would be terribly upset if they were challenged on that position and
lost in good faith in court as that would create a case of precedence
that would be helpful in other regards. Basically, those with the means
to call their bluff stand to lose more than they do.
In the mean time, I don't think it makes sense to diverge too far from
sanity for making stipulations.
--
David Kastrup
le manual. A slur even across the same pitch will be
executed with a separate keypress as opposed to a tie.
I seem to remember that even in Bach's B minor mass (where E12 was not
yet a thing) there is an enharmonic tie (or at least tonal repetition?)
in the transition from "Confiteor" to "Et expecto". I mean, that
transition is a tonal center nightmare anyway.
I'd have to consult my score to pick out the details.
--
David Kastrup
ion of practicality than philosophy what to
use here, and it could even be something else like EnharmonicTie with
both slur-interface and tie-interface.
Tie endpoints tend to be different from slur endpoints since they
connect noteheads more than note columns (in-chord slurs are not really
a good reference since they currently suck with regard to their
positioning).
--
David Kastrup
Jean Abou Samra writes:
> Le 27/09/2020 à 19:37, David Kastrup a écrit :
>
>> (in-chord slurs are not reallya good reference since
>> they currently suck with regard to theirpositioning).
> By the way... if you have information about this, that's very
> welcome i
lly exploited enharmonic equivalence used as a "wormhole" in an
> otherwise purely diatonic tonal system. There can be no question that
> this is semantically a tie.
Thanks for digging this up: I knew there was something like that in
there.
--
David Kastrup
Hans Åberg writes:
>> On 27 Sep 2020, at 19:31, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>>> On 26 Sep 2020, at 18:04, Dan Eble wrote:
>>>>
>>>>> On Sep 26, 2020, at 09:41, Dan Eble wrote
art even in the 2:30
and finally 3:00 (or so) locations which is a bit surprising to me since
I remember how we fought keeping the intonation in line so that the
resurrection trumpets could fall right in. I cannot hear instruments
there right now but I have only builtin speakers at low volume right now
so I may be wrong about that.
--
David Kastrup
an forced to place
there.
--
David Kastrup
-add-text-replacements (list
> text-font-defaults) alist)
>
> modifies text-font-defaults in-place. It looks like the definition being
> changed is the default paper setting, which is shared across files.
assoc-set! on a grob property is not just playing fast and loose across
files but breaks in-file consistency completely as well.
> what was the last version in which this was seen working as expected?
Probably never did but people got lucky.
--
David Kastrup
ps://gitlab.com/lilypond/lilypond/-/merge_requests/431 Due to the
> nature of the issue, I need to run two full doc builds (on master and
> with the change) to ensure it really solves the problem...
>
> Jonas
>
--
David Kastrup
Jonas Hahnfeld writes:
> Am Donnerstag, den 01.10.2020, 14:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Donnerstag, den 01.10.2020, 05:07 +0200 schrieb Werner LEMBERG:
>> > > > > what was the last version in which th
> (./http.texinfo (/home/wl/bug/texinfo.tex
> Loading texinfo [version 2020-06-25.17]:
How does /home/wl/bug/texinfo.tex end up announcing two different
versions of TeXinfo?
--
David Kastrup
te one will be
>> unaffected.
>> Worth adding a note to CG?
>
> Sure, patches welcome 😄
It's more of a safety measure than anything else. If you update from a
repository that lost branches (or has decided not to remove them for
legal or whatever reasons) then your local branch copies are left alone
by default. It's not entirely consistent behavior I think, just a
measure that makes it more likely that some stuff does not magically
disappear everywhere at once.
--
David Kastrup
t needs to create a new stencil, copying the
stencil expression and changing the dimensions.
ly:stencil-set-extent! has been removed in 2.5.17. Extents are not
intended to be mutable as far as I can discern, so if our C++ code does
violate that assumption, it is that code we should fix instead of giving
up on behavior guaranteed from the Scheme side of things.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 22.11.2020, 22:49 +0100 schrieb David Kastrup:
>>
>> To me that seems crazy. Instead \footnote should not modify the
>> stencil generated from its argument in place. If it needs something
>> with different dimensions, it ne
lain that. Then there
is <http://lilypond.org/easier-editing.html>.
You say you program in C++. Where is the startup file for C++? There
is no such thing, but there are various IDEs you can use for writing C++
code. Similar with LilyPond. Frescobaldi is a pretty popular one.
--
David Kastrup
ou want to swap them out.
> That's another hour or so of my life gone.
There is a whole entertainment industry based on the premise that this
is a good rather than a bad thing...
Still, somehow one was less miserly with wasting one's hours on useless
things when one was younger...
--
David Kastrup
current time at a given value.
Isn't that a problem for the operation of Make itself since it relies on
file modification dates?
--
David Kastrup
NR A.12 Text markup list commands
> This now looks as attached.
>
> I'd love to see there
> "
> Used properties
> - split-char (#\newline)
> "
>
> Any chance?
>
> Thanks,
> Harm
>
>
>
It's probably a bug. Try replacing in
(format #f "@item @code{~a} (~a)\n"
in the function doc-markup-function-properties in
scm/document-markup.scm the second ~a with ~s (which should quote
everything in read syntax). This would likely have more consequences,
like when there are string defaults.
--
David Kastrup
Thomas Morley writes:
> Am Do., 31. Dez. 2020 um 00:11 Uhr schrieb Thomas Morley
> :
>>
>> Am Do., 31. Dez. 2020 um 00:00 Uhr schrieb David Kastrup :
>> >
>> > It's probably a bug. Try replacing in
>> >
>> >
issue. Addressing it
would likely require moving the MacOSX compilation environment on GUB
<https://lilypond.org/gub> from Apple's proprietary SDKs (which don't
have anything allowing cross-compilation for 64bit systems) to a form of
free Darwin-only. Certainly a worthwhile goal but probably quite
different from what the OP thinks the problem is here.
--
David Kastrup
Thomas Morley writes:
> Am Do., 31. Dez. 2020 um 12:31 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Am Do., 31. Dez. 2020 um 00:11 Uhr schrieb Thomas Morley
>> > :
>> >>
>> >> Am Do., 31. Dez. 2020 um 00:00 Uhr sc
Thomas Morley writes:
> Am Do., 31. Dez. 2020 um 21:04 Uhr schrieb David Kastrup :
>>
>> Come to think of it: on top of using ~s here, wouldn't it also be
>> necessary to quote characters @ { } by preceding them with @ ?
>
> My knowledge of texinfo is rudimentary.
Thomas Morley writes:
> rtfm tends to help ;)
> Alas, I've no good idea how a `texi-quote` could work. Iiuc, one needs
> more than a simple search/replace.
Just put a @ in front of every @, {, or } ?
--
David Kastrup
Thomas Morley writes:
> Am Fr., 1. Jan. 2021 um 20:07 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > rtfm tends to help ;)
>> > Alas, I've no good idea how a `texi-quote` could work. Iiuc, one needs
>> > more than a simple
((blub
> (define-music-function ((*parser*) (*location*) m2) (ly:music?)
>#{ \tweak color #red $m2 #})))
> #{ $m1 $blub $m1 #}))
>
> \foo c'4
>
> Can this be fixed?
<https://gitlab.com/lilypond/lilypond/-/merge_requests/597>
Would likely warrant some testing...
--
David Kastrup
ne and then it was decided to keep it, as a tribute if nothing
else.
With regard to its value as a contribution, of course these days the
code base has very much diverged and I don't think anybody ever checked
the design or intent of his last changes to figure out what goal he was
workin
odified BSD License", states that it is compatible with the GNU
GPL.
But you'd still have to convince everybody that yet another build system
is just what LilyPond needs.
--
David Kastrup
at could be
> fixed with prominent warnings at appropriate places?
Maybe \bar "|" could just bump the bar number (and reset bar position)?
Can anyone think of a scenario where this would not make sense?
--
David Kastrup
Dan Eble writes:
> On Jan 15, 2021, at 06:53, David Kastrup wrote:
>>
>> Werner LEMBERG writes:
>>
>>>> Add issue #3640 to this discussion. Accidentals, bar numbers, and
>>>> (now) multi-measure rests are all impacted by the fact tha
ompatible. As such it would not make a lot of sense to
place them in a separate, different file rather than extend the existing
one. Or am I overlooking something?
--
David Kastrup
t, this
> will not work.
> The problem is not limited to \note, it would affect commands like
> \beam, \draw-circle etc. as well, if syntax conversions
> would have to be added to 'convert-ly'.
>
> AFAICT the parser solves this problem by checking the call signature of
> the markup command to
> know how many arguments should be there. (and of which type)
> Since \markup commands are user-definable, I don't have any idea how to
> solve this in a general way
> within convert-ly.
>
> Cc'ing David, maybe you have some inspiration for us?
Short of special-patterning the known exceptions... a bit of a
nightmare.
--
David Kastrup
t; write.
>
> (2) Automatically generated references to source code lines,
> something like
>
> file ly/foo.ly, line xxx
>
> for top-level stuff like LilyPond contexts.
Scheme can be told to keep source locations for expressions.
Documentation generation could switch this on and pick the expression
out of the source code instead of using it from the variable when it is
being generated by Scheme.
It's not like the autogenerated documentation is eating the lion's share
of our processing time.
--
David Kastrup
of a technique would fit better with the rest of the
> articulations.
\segnoSign etc maybe? It makes at least the statement that it's only
the sign without function attached to it. \segnoMark could be
misinterpreted to work like a mark rather than an articulation.
--
David Kastrup
>
>
> What am I missing?
The file
$HOME/.ssh/id_ed25519
or wherever you are supposed to store the secret key corresponding to
your SSH key pair.
For R/O (public) access, there will be different credentials you can use
without your personal secret key copy.
--
David Kastrup
Thomas Morley writes:
> Am So., 28. Feb. 2021 um 19:16 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Hi,
>> >
>> > for hunting a bug I revived an older LilyDev in Virtual Box (based
>> > on Debian-8).
>> >
>&
is the one Guile-using project that is actually
> essential and irreplaceable for stuff I do as Hobby (music).
If you do serious work with LilyPond and have a useful installation,
then the LilyPond file
\void \displayScheme #(version)
is likely to output
"1.8.8"
on the console.
--
David Kastrup
e I would like \fixed to have" is more a function of
persuading a significant majority that your interpretation of \fixed f''
is clearly the best for the sake of all users.
And then you still need to think about how to implement it. That's not
trivial either.
--
David Kastrup
601 - 700 of 6220 matches
Mail list logo
