> I want to design an app like Frescobaldi but with Chinese Jianpu
> input.
I strongly suggest that you don't do that. Instead, please try to
extend Frescobaldi with a Jianpu input mode! I'm sure that Wilbert
will be happy in helping you to do that.
Werner
> Using Arabic numerals for pitches in LilyPond seems like a world of
> pain, [...]
Well, it was used in Europe, too, called the 'Galin-Paris-Chevé'
system:
https://en.wikipedia.org/wiki/Numbered_musical_notation
and the results done with LilyPond look quite good:
https://ssb22.user.srcf.n
Before investing more time into it I wonder whether the use of
'libfaketime' would be a valid solution for creating reproducible
builds. According to 'pkgs.org' it is available for most GNU/Linux
distributions; it is also part of both MacPorts and Homebrew.
https://github.com/wolfcw/libfaketi
>> The idea is to do the following:
>>
>> export LD_PRELOAD=/usr/local/lib/libfaketime.so.1
>> export FAKETIME="2020-12-24 00:00:00"
>>
>> make all
>> make doc
>>
>> This freezes the current time at a given value.
>
> Isn't that a problem for the operation of Make itself since it
> relie
>> Before investing more time into it I wonder whether the use of
>> 'libfaketime' would be a valid solution for creating reproducible
>> builds.
>
> My 2 cents: The widely accepted solution is SOURCE_DATE_EPOCH and if
> there is anything in LilyPond itself that inserts unreproducible data
> (int
> I definitely consider intercepting various syscalls by means of
> LD_PRELOADing more intrusive than setting a single environment
> variable that was invented for the purpose of setting timestamps.
> Just think of a new shiny syscall that might add a new source of
> non-reproducibility.
What 'ne
>> I definitely consider intercepting various syscalls by means of
>> LD_PRELOADing more intrusive than setting a single environment
>> variable that was invented for the purpose of setting timestamps.
>> Just think of a new shiny syscall that might add a new source of
>> non-reproducibility.
>
There are six empty PNG files in `Documentation/pictures`:
nav1-active.png
nav1-bg.png
nav1-hover.png
nav2-active.png
nav2-bg.png
nav2-hover.png
Is this really correct?
Werner
>> What 'new shiny syscall' shall influence the creation of PDFs,
>> specified by international standards? I think this is a straw man
>> argument.
>
> For example a new syscall to get the current time. While
> improbable, just look at things like the new statx call, it happens
> from time to t
>> There are six empty PNG files in `Documentation/pictures`:
>> nav1-active.png
>> nav1-bg.png
>> nav1-hover.png
>> nav2-active.png
>> nav2-bg.png
>> nav2-hover.png
>> Is this really correct?
>
> I don't think it's correct. If you read here:
>
> https://gitlab.com/lilypond/lilypo
> I couldn't figure how to let print
> #\newline
Try the ugly
#@backslashchar{}newline
:-)
Werner
> Interesting, the brew formula uses the pre-built binaries which are
> 32- bit only (due to licensing issues, see below):
> https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/lilypond.rb
> That's more of a packaging issue in brew, LilyPond should build fine
> with Clang since a year or s
> Does this warning indicate something amiss in my build environment?
>
> ```
> Layout output to `./1a/lily-d0aeef0b.eps'...
> fatal error: Font NotoSansCJKjp-Regular cannot be loaded via Ghostscript
> because it is an OpenType/CFF Collection (OTC) font.
> ```
What font name does `fc-list` show
>> Hi all and happy new year 2021 to everyone!
>
> happy new year to everyone, and I hope everyone is healthy and safe.
I wish the same :-)
>> There were no bug reports for 2.21.82 and no other Critical issue
>> that [..]
>
> Sounds good to me
+1
Werner
> Used properties (Werner's proposal):
> @itemize
> @item @code{number} [default: 3]
> @item @code{pair} [default: (0 . 0)]
> @item @code{empty-list} [default: ()]
> @end itemize
Actually, my suggestion should be formatted like this:
@itemize
@item @code{number} [default: @code{3}]
@item
> https://codereview.appspot.com/560030044/
Thanks for the reminder; apparently it has been forgotten to be
applied. Valentin, could you submit a Merge Request?
Werner
> Add issue #3640 to this discussion. Accidentals, bar numbers, and
> (now) multi-measure rests are all impacted by the fact that \bar "|"
> does not create a new measure.
Maybe the whole thing is primarily a documentation issue that could be
fixed with prominent warnings at appropriate places?
>>> Add issue #3640 to this discussion. Accidentals, bar numbers, and
>>> (now) multi-measure rests are all impacted by the fact that \bar
>>> "|" does not create a new measure.
>>
>> Maybe the whole thing is primarily a documentation issue that could
>> be fixed with prominent warnings at appro
> before that date last year (June 22, 2020) it was possible to create
> CI artifacts that never expired. This posed problems (huge data
> volume) for GitLab Inc running gitlab.com, so they decided to add an
> expiration date retrospectively. I guess that some may start to
> expire around now w
According to
https://ports.macports.org/port/lilypond/summary
the problems with the dependencies have been fixed; this means that
lilypond should now install fine using MacPorts on Apple silicon.
Werner
> Do you know of documentation that details what is and is not allowed
> in an ABI-compatible change?
You might try
https://lvc.github.io/abi-compliance-checker/
Werner
>> I have updated the accordion registers that are in accreg.scm.
>> [...]
>
> At first glance, it would appear that all of those changes are
> intended to be upwards-compatible. As such it would not make a lot
> of sense to place them in a separate, different file rather than
> extend the exis
> the rectangular boxes are vertically centered, at least on my
> screen. Can you check it?
Yes, they are now, thanks! I've checked with extreme magnification
using `gv`.
Werner
> with 2.22.0 released, I think we shouldn't wait too long before the
> first development release of 2.23.
+1
Werner
Is there still any benefit in using the
`scripts/auxiliar/update-patch-version` script as described in the
Contributor Guide? It seems to me that this and the related
documentation should be simply deleted.
Right now I'm completely revising `programming-work.itexi`, so I can
take care of that,
>> Is there still any benefit in using the
>> `scripts/auxiliar/update-patch-version` script as described in the
>> Contributor Guide? It seems to me that this and the related
>> documentation should be simply deleted.
>
> I don't, and if need be we can run the single command:
> $ git grep --na
>> > It would be great if you can structure the revision as incremental
>> > updates and not as a big dump. Those are quite tedious to review
>> > and usually take much longer to go through...
>>
>> Unfortunately, this is next to impossible since there are so many
>> changes.
>
> No, it is poss
>>Unfortunately, this is next to impossible since there are so many
>>changes. I will provide a PDF that holds the changed pages so that
>>you and others can simply read what's written there, comparing it
>>with the current version of the Contributor guide if necessary.
>
> It was this condition
Right now, some overlong lines are auto-generated in the Internals
Reference. As an example, look at the entry for `KievanStaff`, which
contains the following.
• Set translator property autoAccidentals to:
'(Staff #
#)
In the file `engraver-init.ly` you can find the following
> Right now, some overlong lines are auto-generated in the Internals
> Reference. As an example, look at the entry for `KievanStaff`,
> which contains the following.
>
> • Set translator property autoAccidentals to:
>
> '(Staff #
> # measurepos)>)
>
> In the file `engraver-in
We should run `make grand-replace` to update all copyright years.
Since this is a completely mechanical thing to do, I suggest to submit
the MR, wait until a build was successful, then immediately merging
and committing it, bypassing the normal reviewing cycle. This should
minimize the hassles w
>> We should run `make grand-replace` to update all copyright years.
>> Since this is a completely mechanical thing to do, I suggest to
>> submit the MR, wait until a build was successful, then immediately
>> merging and committing it, bypassing the normal reviewing cycle.
>> This should minimize
> To be clear, I do *not* plan to run grand-replace.py on the stable
> branch. Instead I'll "just" update the few user-facing strings, in
> lily/main.cc:273 and scripts/*.
OK. I misunderstood.
Werner
> Hi, I'm getting a build failure:
> home/abuild/rpmbuild/BUILD/lilypond-2.22.0/mf # make
> Making mf/out/feta11.pfb < mf
> mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find
> another way to convert feta11.pt1 to feta11.pfb
You seem to have a problem with `t1asm` (wh
>> Right now, some overlong lines are auto-generated in the Internals
>> Reference. [...]
>
> It seems to me that during the creation of the documentation,
> expansion of the property value should be prevented.
Continuing my monologue...
I guess that if we have
foo = #bar
in LilyPond then `
> let me add a few thoughts...
Thanks for chiming in.
> For those static ones I have the strong opinion, we should always
> print them expanded and literally, even for a longer list. Thus
>
> • Set translator property ottavationMarkups to:
>
> '((4 . "29")
> (3 . "22")
> (2 .
>> (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 pic
> gperf installed, retrying...
>
> Though, if gperf is needed and missing ./configure should error,
> imho
Not necessarily. I guess that the file created by `gperf` is part of
the tarball. However, you are installing directly from the git
repository. In most cases this means that you have to i
> I am attempting to compile lilypond 2.22 on xubuntu 20.04 using "make
> all". I get the error:
>
> /usr/bin/ld: cannot find -lguile
>
> Should be a simple thing to set a path to the guile 1.8 libraries -
> but I cannot find them, either.
Most likely you have to compile guile 1.8 by yours
Hello Owen,
> Attached is a spreadsheet with my plans for naming the Clef, Time
> Signature, Number, and Accidental glyph categories, as enumerated at
> http://lilypond.org/doc/v2.23/Documentation/notation/the-emmentaler-font.
> The SMuFL names were taken from the Standard Music Font Layout
> S
> I'd like to give an update on the status of Guile 2.2, including
> some benchmark numbers. See the end for my conclusions, but I'd
> welcome comments on your take.
Thanks for doing the comparison.
This has certainly be mentioned somewhere, but what exactly is the
advantage for LilyPond of us
> I had already replied that I don't like that option; it was always a
> given for me that LilyPond would move on.
Your arguments are sound, no question, ...
> Guile 2.2 also makes binary distribution much nicer (because there
> no more shared srfi libraries, so lilypond can be linked as one
>
>> It is very unfortunate that more recent Guile versions cause such a
>> serious deterioration for LilyPond. Maybe it makes sense for the
>> foreseeable future to stay with the status quo, this is, using
>> Guile 1.8 as much as possible,
>
> For reference: Ubuntu 16.04, the longest supported ve
>> Almost all developers use a Unix-like OS and can be thus served
>> with Guile 1.8.x! Are there actually LilyPond developers who work
>> natively with Windows or MacOS? With 'natively' I mean using a
>> binary specifically compiled for that platform and not a virtual
>> box.
>
> Adding a mix
>> Note that I don't want that we stay with Guile 1.8 forever, but the
>> slowness of 2.x and 3.x is a serious issue. To sacrifice this
>> still enormous speed advantage just for the sake of orthodoxy seems
>> wrong to me.
>
> So 10% performance regression for users is enormous?
This would be a
>> ... you were talking about advancing to Guile 2.x as the next step,
>> and if I have understood your original e-mail correctly, this speed
>> is only available with 3.x.
>
> Then please re-read the initial message *carefully*!
I stand corrected. Somehow I got the impression that compiled Sc
>> I stand corrected. Somehow I got the impression that compiled
>> Scheme code is a 3.x thing only.
>
> So with that hopefully clarified, does this change your assessment
> that we should work towards forking our own Guile 1.8?
Working towards a fork of Guile 1.8 was never meant to be a good
o
>> Working towards a fork of Guile 1.8 was never meant to be a good
>> option, rather as a last resort if speed differences make normal
>> work too painful.
>
> Well, the question of this thread was: What is "too painful"? Do we
> require less "speed differences" than what I measured? In general
>> For me, the speed of Guile 2.x without compiled Scheme bytecode
>> would be too painful.
>
> Agreed for user installations, but we have a work-around there. So
> what about development? Do we *require* compiled bytecode to work
> there? [...]
I don't know, really. I have zero feeling for
> By now I guess just nobody cares to tell me in advance and whatever
> I choose to do, it will be questioned when I try to proceed to the
> next steps...
Well, I *do* care, but I simply don't have enough knowledge to give
even an uneducated guess as answers to your questions, sorry.
Werne
Right now, the NR section on footnotes looks very ugly. Reason is
that footnote marks are not included in skylines; as a consequence,
they are cut off, see attached images. (BTW, it seems that this fact
is not mentioned in the documentation.)
Do you have suggestions how the samples in the NR ca
>> Right now, the NR section on footnotes looks very ugly. Reason is
>> that footnote marks are not included in skylines; as a consequence,
>> they are cut off, see attached images. (BTW, it seems that this
>> fact is not mentioned in the documentation.)
>>
>> Do you have suggestions how the sa
Folks,
since some weeks I encounter a very strange problem while compiling
git HEAD. I get different rendering results for
make doc
vs.
make doc -j12 CPU_COUNT=12
as the attached `1-*.png` images show: in most cases, the glyph
`accidentals.sharp` in the `-j12` build is replaced with
`ac
> I get different rendering results for
>
> make doc
>
> vs.
>
> make doc -j12 CPU_COUNT=12
I forgot to mention that this problem can already be seen in the EPS
files, which means that it is not a problem of ghostscript. It's
either LilyPond itself or the Pango library (since apparently on
> [...] To reiterate, there should be (as of now) no change for
> existing groups or users. Nevertheless I'll finally try to get
> LilyPond accepted into GitLab's Open Source Program, as I already
> wrote in September...
Thanks for taking care of this!
Werner
>> > for your information and to prevent others from wondering: The
>> > bug fix release 1.48.3 of Pango breaks LilyPond's processing with
>> > multiple jobs. [...]
>
> Now fully resolved with 1.48.5 🙂
Thanks for testing! How shall we proceed?
Werner
>> > Now fully resolved with 1.48.5 🙂
>>
>> Thanks for testing! How shall we proceed?
>
> What do you mean? Versions 1.48.3 and 1.48.4 use more memory if you
> compile hundreds of tiny files (as for the regression tests), but
> that's probably not something users do. The issue with multiple jobs
This might be of interest:
https://ghostscript.com/pdfi.html
Werner
Please have a look at
https://gitlab.com/lilypond/lilypond/-/issues/6142
Is there a workaround?
Werner
> I'd argue that if we have
>
> \tempo 60
> \time 6/8
>
> then we should likely interpret this (regarding the MIDI playing
> speed) as
>
> \tempo 60 = 4.
> \time 6/8
Looks OK for me. This is a default value that LilyPond should guess,
right?
> In other words: looks like a long-standing mess i
Hello Owen!
> Instead of an Excel sheet, I've prepared a somewhat janky GitHub
> Pages site here: https://wolfgangsta.github.io/emmentaler-bravura/.
> It includes my current opinions on what glyphs should match up
> where, and indicates possibly contentious decisions.
Aah, *much* better, thanks
>> * Number sets: Since LilyPond uses the same glyphs for time
>> signatures, figured bass, and fingerings, we probably have to map
>> the Emmentaler glyphs to all SMuFL sets, irrespective of the
>> size. In general, I think that size issues are only to be
>> considered if the size matters
>> Indeed. Care to open an SMuFL issue at their site?
>
> Do you mean we propose that SMuFL *itself* should explicitly
> recommend that programs default to timeSigX when the other number
> sets aren't present?
I think I was slightly confused, trying to apply Unicode principles on
SMuFL. Howeve
>> For those who are interested: here is an updated version of my
>> cairo patch.
Excellent, thanks!
>> If we kick out ghostscript the \postscript markup will die a lonely
>> death.
>
> I'd retain the PostScript backend for special purposes.
+1
> A trickier question is how to use it from the
Hello Knut,
> For those who are interested: The aattached patch adds uri
> hyperlinks and internal page hyperlinks (forward references to page
> numbers have a problem). Also included: partial ellipses, needed by
> the woodwind diagram code.
All of your code looks very good. Thanks again for
> I noticed that there are some obsolete ones that should be deleted:
>
> * Task: I *think* this comes from "Type: Task" on SourceForge and
>never had issues.
> * Cant_verify: As we don't do verification anymore, I don't think
>there's much gain from labeling one open and two closed issu
> No, it's definitely too soon for a merge request. A few
> stencils->cairo procedures need to be added, a bit of error handling
> (to prevent at least possible segfaults) is necessary, a bit of
> logical cleanup is desirable, etc.
Well, you can start the commit message of the merge request wit
> So the new situation is as follows:
>
> * Emmentaler: basically all issues that were labeled "Font" or
>"Glyph" on SourceForge, plus open ones that belong there
> * Font: support in LilyPond, including text fonts
+1, thanks.
Werner
>
> Today, I learned that OpenType has a feature to make capital letters
> small. Setting smcp and c2sc features together renders all letters
> in small caps regardless of the underlying capitalization.
>
> Good news, right? but I also learned that LilyPond's default font
> doesn't have these fe
> In framework-ps we have this code at lines 501+
>
> [...]
> (else
> (ly:font-sub-fonts font
> [...]
>
> The 'else' clause is different. A diagnostic patch showed that it is
> never executed during 'make doc'.
>
> Does anybody know a font/example that triggers usage of the code in
>
>> In framework-ps we have this code at lines 501+
>>
>> [...]
>> (else
>> (ly:font-sub-fonts font
>> [...]
>>
>> The 'else' clause is different. A diagnostic patch showed that it is
>> never executed during 'make doc'.
>>
>> Does anybody know a font/example that triggers usage of
>>> Does anybody know a font/example that triggers usage of the code in
>>> the 'else' clause?
>>
>> This is Han-Wen's code from 2005 (commit ea6d4c224d9) to handle the
>> `LILF` table in the Emmentaler font. Looking into
>> `gen-emmentaler-brace.fontforge.py` it should be related to braces
>> in
> No, we're in the post-C++11 era,
Are we? I thought that LilyPond shouldn't use features more recent
than C++11.
Werner
> A bit of news on the SMuFL front. I've dropped in the next few
> Emmentaler categories (Default Noteheads, Special Noteheads, and
> Shape-note Noteheads), so feel free to give it a look at
> https://wolfgangsta.github.io/emmentaler-bravura/. Please let me
> know what you think, especially regar
>> * Regarding `noteheads.uM2`, I don't see a problem with removing the
>>hard-coded stems.
>
> That's good to hear. If we do, though, we'll have to reconcile
> breve/longa sidebars with Lily's customizable stems. I'm thinking
> we keep our breve glyphs for SMuFL compatibility, but in LP it
Hello Owen,
thanks for updating the page. Everything looks very nice, and this
time I don't have comments :-)
Werner
In `notation.pdf`, section 'A.23, Scheme functions', the function
header
(define-safe-public (check-context-path path #:optional location)
gets currently translated to
check-context-path path . lambda*:G59
which looks weird. David, in case this is unavoidable (I remember
faintly that you
>> I remember faintly that you've mentioned something along this
>> direction [...]
>
> see https://gitlab.com/lilypond/lilypond/-/merge_requests/808
Ah thanks, this was it.
Werner
>> In `notation.pdf`, section 'A.23, Scheme functions', the function
>> header
>>
>> (define-safe-public (check-context-path path #:optional location)
>>
>> gets currently translated to
>>
>> check-context-path path . lambda*:G59
A quick work-around is to use Guile 2.x, as Jean has reported
>> A quick work-around is to use Guile 2.x, as Jean has reported in
>> !808...
>
> Is that actually better? Last time I had contact with Guile-2.x in
> that respect, it replaced the argument lists by generic a b c d .
> That would be different here?
I don't know. I have always used 1.x; I have
Function `elbow-hairpin` is defined as
(define ((elbowed-hairpin coords mirrored?) grob)
...
(export elbowed-hairpin)
Functions `flared-hairpin` and `constante-hairpin` are defined as
(define-public flared-hairpin
(elbowed-hairpin '((0 . 0) (0.95 . 0.4) (1.0 . 1.0)) #t))
(defi
> So, I finally succeeded [...]
Thanks a lot for your efforts!
Werner
Due to security concerns the ` ... ` extension to embed
LilyPond (and ABC) scores in Wikipedia pages that are displayed
automatically were disabled for more than a year.
https://phabricator.wikimedia.org/T257066
This has been reactivated now. It seems, however, that not all
details have been
> With MR 897, I have been able to run the doc build through Cairo.
> Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller.
Great!
> -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf
This is still far too large IMHO. On my GNU/L
> I'll look into PDF processing software. AFAICT, the subsetting
> retains the character mapping of the original font, so I think it
> should be possible to rewrite it to embed the Emmentaler font once,
> point all font references to the full font, and elide all the
> subsetted versions.
Thanks
>>> Most PDF readers have a mapping from Adobe-Japan1 CID to Unicode
>>> code points as follows.
>>> https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>>
>> Is it impossible to discover this mapping from the OTF file alone?
>
> If I understand co
> After a rather long hiatus, here's the next batch of glyphs (Script
> glyphs): https://wolfgangsta.github.io/emmentaler-bravura/. [...]
Again many thanks for your investigations.
* about signum congruentiae: I agree with you that the exact shape is
not significant since the variety of this
>> * About the rotated wiggle glyphs in Bravura: Do you have any idea
>> why this is so? If not, can you please ask the SMuFL people? It
>> looks definitely wrong to me! They should either correct the
>> font or provide glyph name aliases for horizontal typesetting
>> (assuming that glyp
> PS. Speaking of that appendix: I don't know much about typography,
> but the kerning of "Av" in
>
> doesn't seem right to me. Is that as it should be? (The image is
> from the pdf in the official 2.22/2.23 build.)
... no image...
Werner
>>> but the kerning of "Av" [...] doesn't seem right to me. Is that
>>> as it should be?
Yes, it is correct – and ugly, I agree. The Computer Modern font
family doesn't contain kerning values between 'A' and 'v'.
Werner
What about using '**' to indicate repetition? Other programming
languages use '**' to indicate exponentiation, thus the analogy to
repetition wouldn't be too far-fetched.
c'*2*0.5 ** 5
{ c'2 d } ** 4
No idea whether this is easily doable in LilyPond's grammar.
Werner
>> And I think it would be nice to have an even more natural variant
>> for that; I think it's reasonable to provide & show/recommend
>> convenient solutions for standard tasks (rather than say "you can
>> define your own abbreviation here if you know how to do so") - for
>> example,
>>
>> \*2 "
>>> Perhaps the LilyPond syntax might be tweaked so that identifiers
>>> starting with a UTF-8 multi-byte (high bit set) character do not
>>> need the backslash. Then simply ×2 would look good.
>>
>> This reminds me of TeX's 'active characters'. I think we shouldn't
>> go this route. IMHO, a co
>>> The idea here is different, it is for identifiers, and in the
>>> input syntax only, does not change the internal semantics at all.
>>> It is good not having to type backslash when a command is used.
>>
>> Really? I highly doubt that. In particular, what about lyrics
>> mode?
>
> The idea w
Folks,
This is a comment of mine from !929:
==
The change to enable pairs [in `#(set-default-paper-size)`] is almost
trivial:
```
--- a/scm/paper.scm
+++ b/scm/paper.scm
@@ -314,7 +314,9 @@ unless explicitly overridden in th
>> #(set-default-paper-size (cons (* 100 mm) (* 50 mm)))
>> ```
>>
>> doesn't work;
>>
>> What must I do to make 'mm' and similar dimension scale values
>> available at the top level?
>
> Why would you not use it in the paper block? mm is not a constant,
> it depends on the output scale.
OK, t
> The paper size strings passed to `set-default-paper-size` *do*
> contain the 'mm' variable, see `paper-alist`. Is the expansion of
> 'mm' delayed? Isn't there a possibility to do the same on the top
> level?
I mean, passing numerical values plus a dimension scaling variable
like 'mm' to `set
> 28x { d a b fs | g d g a }
I like that, thanks! Carl's concerns w.r.t. whitespace are valid,
though. Would it be possible to make the invalid syntax '28 x'
produce a nice error message like
invalid , did you mean '28x'?
Werner
>> 28x { d a b fs | g d g a }
>>
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/937
>
> That is a clever proposal. I am already fond of it. Thank you.
+1
>> I like that, thanks! Carl's concerns w.r.t. whitespace are valid,
>> though. Would it be possible to make the invalid syntax
>> OK, thanks for the pointer. But I wonder what exactly the problem
>> is: The paper size strings passed to `set-default-paper-size` *do*
>> contain the 'mm' variable, see `paper-alist`. Is the expansion of
>> 'mm' delayed? Isn't there a possibility to do the same on the top
>> level?
>
> You
501 - 600 of 3522 matches
Mail list logo
