James E. Bailey a écrit :
Am 25.03.2009 um 14:41 schrieb Graham Percival:
Nothing; they come from exactly the same source. The version in
the AU is going to die soon, where "soon" means "within 4 months".
So then why the difference? I should think a one line command to get
the source is eas
Graham Percival a écrit :
On Sat, Mar 28, 2009 at 11:57:06AM +0100, Reinhold Kainhofer wrote:
- -) git fetch + git rebase will take that local commit and append it
after
the HEAD of current master, so it will be
yourcommit (=new local master)
|
current_remote_head
Hi,
Patrick McCarty a écrit :
This patch fixes `make install' on git master.
-if (re.search(r'\'dash-fraction', str) or re.search(r'\'dash-period', str):
+if (re.search(r'\'dash-fraction', str) or re.search(r'\'dash-period',
str)):
The parenthesis after 'if' should be removed inste
Graham Percival a écrit :
Not only that, but with a minimum of effort. IMO, people adding
new features should only be required to write one .ly file (for
input/regression/ ); they shouldn't need to do any other manual
tweaking to get a snippet in input/lsr/.
I partially agree. People should
Carl D. Sorensen a écrit :
When you run makelsr.py, do you get a message about new snippets that have
been added, so you know snippet names to search the documentation for?
After you have run makelsr.py and cheked for unsafe snippets with the
recommended commands, just look for "new file" in
John Mandereau a écrit :
People should never be bored by manually editing snippets in input/new
to write them in input/lsr, as this can be handled automatically by
makelsr, but there are some formatting requirements for stuff in
input/new that are not necessary for regression tests, e.g
Hi,
This is a follow-up of thread "Why is it _still_ so freaking hard to get
info with images?"
http://lists.gnu.org/archive/html/lilypond-devel/2009-03/msg00144.html
I had the changes for this for weeks in my working tree; it mainly
renames targets to use more standard names:
web -> doc
we
John Mandereau a écrit :
it mainly renames targets to use more standard names:
web -> doc
web-1 -> doc-1
web-clean -> doc-clean
web-install -> install-doc
web-uninstall -> uninstall-doc
info-install -> install-info
...and here's a patch for GUB3.
John
diff --git a/gub/
John Mandereau a écrit :
Thanks for yout work Carl; maybe this could be completed with
information from input/new/README. Btw we may want to junk
input/lsr/README, as (or if) its contents is in the CG.
IMHO you should push this to Git soon, as all essential techical
issues are solved
Graham Percival a écrit :
WTM is "web-1"?
Do "make help"... or read below.
If you're renaming it anyway, why not give it a
more intuitive name?
It's the first stage of docs building, but for the developer or doc
writer it just means building PDF and Info docs, so what about
pdf-info
?
John Mandereau a écrit :
John Mandereau a écrit :
People should never be bored by manually editing snippets in
input/new to write them in input/lsr, as this can be handled
automatically by makelsr, but there are some formatting requirements
for stuff in input/new that are not necessary for
Graham Percival a écrit :
On Fri, Apr 24, 2009 at 11:19:15AM +0200, John Mandereau wrote:
pdf-info
Hmm, that sounds like it's information about the pdf. How do you
feel about "doc-init" or "doc-base" or "doc-stage-one" ? I must
admit that none of
Carl D. Sorensen a écrit :
On 4/24/09 9:06 AM, "Graham Percival" wrote:
Actually, we should junk all README files (including
input/new/README); developers should have a single place (the CG)
to look.
IMHO we should keep READMEs whichpoint to the right chapter of the CG.
This and the t
Anthony W. Youngman a écrit :
Oh MAO No.!
text is okay, but if you mean GNU info, I absolutely HATE that. A
simple text or pdf that I can read top-to-bottom is fine, but please
DON'T foist on us a hypertext system that a lot of people don't have a
clue how to use.
RMS goes on about
Hi Carl,
Carl D. Sorensen a écrit :
Some time ago I proposed adding a section to the documentation on the
lilypond parser grammar. I didn't know how to follow up on it then, but I
still think it's useful, even if it's not perfect. And I know a lot more
now.
I think it's useful too.
What w
Hi Carl,
Carl D. Sorensen a écrit :
I've attached a patch that puts the grammar in the Notation Reference as an
appendix, given that lilygrammar.txt is found in Documentation/user.
I called it ly-grammar.txt.
I can't commit these changes myself, because they'll break compiling if the
makefi
Jan Nieuwenhuizen a écrit :
Thanks, please ping me when this is in lilypond master?
It is :-)
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reinhold Kainhofer a écrit :
Just to be sure: Am I correct that the docs build was switched in git from
"make web" to "make doc"?
So, all I have to do is to change "web" to "doc" in the build script on the
server and everything should work as before, right?
The answer to both questions is "
Graham Percival a écrit :
Is it worth defining our own function
replaceOnly("\\octave", ...)
which does
re.sub("\\octave[?a-z,A-Z]", ...)
or whatever the regex was?
I imagine that almost every convert-ly rule would benefit from
"match this command, and only this command" rules, so this could
Jonathan Kulp a écrit :
Ugh. I have a merge conflict upon pulling. Did I mess up the patch?
What are the conflicting files? Your patch is the last commit on master,
so if Trevor applied it without amending it, the conflict is likely
related to changes other than this patch you made locally.
Carl D. Sorensen a écrit :
I've tried adding to the parser, but it seems that my changes are not being
compiled.
Is there a dependency that will cause the parser to be recompiled, or do I
have to do make clean?
I've tried touching parser.yy, and that seems to have no effect.
I'm a bit puzzle
Jonathan Kulp a écrit :
The conflicting files are exactly the ones I modified to create the
patch. True, the CG guide has a section on conflict resolution but
it's not finished yet.
This is true the CG is not finished, but I don't see the need to add
anything to this section, as the referenced
Jonathan Kulp a écrit :
@Werner: I don't even know what GNU make extensions are so hopefully I
can keep them out of the sample makefile. :)
There is no need to hope this, just have a look at GNU Make manual,
which clearly documents which features are GNU extensions IIRC.
This is the kind of info
Jonathan Kulp a écrit :
BTW I now have working makefiles for a lilypond-book (LaTeX type)
project and for a symphony I've engraved with targets of "score,"
"parts," "midi," and "all." The parts are unsuitable for actual use
but they're sufficient to test the makefile and the build process.
[s
pe...@chubb.wattle.id.au a écrit :
If you use GNU extensions, then here's the Makefile I generally use,
to convert everything in the current directory.
Your makefile is certainly useful for many pruposes, but it doesn't take
included files into account:
it will try to build those who have a .
Jonathan Kulp a écrit :
Thanks for looking at this, John. I've gone through the two makefiles
and updated according to your advice, and have also made changes based
on recommendations in the GNU Make Manual, such as specifying the
shell and defining unusual utilities in variables (viewer as
"a
Reinhold Kainhofer a écrit :
Shouldn't this be rather done with prerequisites, variable substitutions and
some generic rules?
This is exactly what I wrote, isn't it?
movement_pdf_target is a phony target rule template, which I apply
to the list of movements MOVEMENTS, and I defined a generic
Anthony W. Youngman a écrit :
I think you missed the "&" in my code :-)
If the "wait" isn't there, the mv will fail because there won't be any
*.pdf files for it to move. Werner's point about multiple invocations
of lilypond is very valid, but on a multi-processor machine my
technique will us
Francisco Vila a écrit :
I've added the committish references to Spanish translations in
input/texidoc. Now that I have found this message from John and that I
have seen what the other references look like, I am not sure the
mechanism is going to work in its current status. More below,
Perm
Francisco Vila a écrit :
Permission to bulk fix it into the last version, in all languages.
Well, I was really offering myself to do it.
Sorry, I didn't understood. Of course you're welcome to do it,
unless you waste your time fixing all committishes by hand.
Best,
John
__
Graham Percival a écrit :
Also, please ask him if lsr-0.4-src.tar.gz is the latest version.
It's dated 30-oct-2007, so I doubt it... but I'd really like to
get the source code.
I sent a patch to Sebastiano based on this version on the sources; he
applied it, and he probably amended it so it coul
Graham Percival a écrit :
Also, I'm slightly leery about how the Makefile stuff would be
introduced -- it should be obvious that this only works on linux
and osx (by default), and would require a lot of additional
software to run on window.
A default Cygwin installation provides all you need f
Till Rettig a écrit :
This translation interface is getting more and more tricky it seems (I
mean technically)
Speaking of, my next task on the translation infrastructure is
simplyfing it a little, i.e. translating node names and titles in
Texinfo sources, which will take 10 hours including the
Francisco Vila a écrit :
it is done;
Cool, thanks!
committishes themselves are not checked
They can now, but I was puzzled by the truckload of bad committishes I
found in Spnaish texidocs, so I applied my auto-committish-setting hack
to them too. I'm not very sure on the correctness of the
Francisco Vila a écrit :
Well, it seems that we can ignore all the diff lines that do not touch
texidoc= or doctitle= fields on files in lsr/ ; so it's not that bad.
Is this right?
It is. This will remain as much cumbersome until LSR snippets (and the
associated data: title, description...)
Till Rettig a écrit :
its great fun, there is really a lot. ;-) The changes are about the
German translation being also added to the .ly file. That's a tricky
case. I will always have to update snippets two times: one time when
translated and the second time after the next lsr-update that adds
Till Rettig a écrit :
Hi John,
somehow the section names don't get translated in the pdfs that are
produced by "make doc". I can see they are translated on the compiled
version on the web, but why don't I get them? :(
I can't answer without more details: Git committish, some of the titles
t
Francisco Vila a écrit :
By default I couldn't guess which one to put,
What about the last revision of the associated .ly file in input/lsr?
Isn't it the place where you took the text to translate?
input/new/foo.ly would be OK if we had all snippets there.
so I put the comm. of a
merge node
Carl D. Sorensen a écrit :
I would recommend that it either be left in english, or translated manually
for now. That is a temporary hack until the great website redesign, which
will be accomplished starting in two weeks, I think.
I hope translators won't have to wait for the website redesig
Till Rettig a écrit :
I just realized that on the web page there is now an addition for the
windos download entry about lilypond being a command line programm and
so on. This is nowhere translated. I guess it should be in the po.s.
Do we have to add it manually there?
The POs weren't updated, s
Francisco Vila a écrit :
2009/5/22 John Mandereau :
For previous work it is too late, but for future work, run makelsr.py
before committing to Git -- read the CG on snippet handling for more
details.
I'm afraid I don't understand how running makelsr.py changes what is
com
Jonathan Kulp a écrit :
Variable Name: GIT_EDITOR
Variable Value:
This should be added to the CG. Who's got responsibility for the git
part
of the CG?
To answer two questions at once, I'm pretty sure Trevor is using
Windows to do git patches, and I believe he's also the one who wrote
Francisco Vila a écrit :
2009/5/25 Wilbert Berendsen :
http://lilypond.org/web/documentation still shows 2.10 as latest stable if NL
(Netherlands) is the preferred language (even though the page is in English).
This is probably the same behavior whatever your preferred language.
And
Francisco Vila a écrit :
2009/5/25, John Mandereau :
You should run makelsr.py *before* you commit changes to texidocs, not
after. Try it as explained in the CG, and you'll see (how) it works.
Hello, I'm in trouble. I have run makelsr.py and git status gives
Before
Francisco Vila a écrit :
Yes, I don't see anything strange except a "not smart enough" message.
I am using only an installed, fresh compiled Git snapshot.
Did you pass makeslr.py an argument? You shouldn't have, unless you know
why.
No.
Then makelsr.py must be bogus; it should not de
Carl D. Sorensen a écrit :
Mark,
I appreciate your good work on these patches.
So do I :-)
2) I'm not sure how to handle patches to translated documents. I know that
the translations need to follow a particular commit of the english docs. If
the change in the translated documents refle
Carl D. Sorensen a écrit :
And I do believe that the po/* files need to change, because the english is
being changed, but I'm not sure of the detailed process to make that happen.
Again, see po/README. When you estimate the strings are not going to
change too soon, bug me and I'll trigger the
Carl D. Sorensen a écrit :
OK, so to make sure I understand correctly,
a) The changes to Documentation/de/* that move Lilypond -> LilyPond are OK
to commit, even though the commitish in the header of this file won't be
updated.
b) the changes to po/* are NOT Ok to commit.
Is this right?
Yes
John Mandereau a écrit :
I thought all this policy was explained in the CG for a) and in
po/README for b).
BTW we should probably create a section in the CG for Git committers who
apply patches in areas they understand but are not used to their
policies, which would reference specific
Carl D. Sorensen a écrit :
So, in this particular case, changing Lilypond to LilyPond qualifies as a
simple text subtitution, I guess?
Yes.
My confusion came from not understanding that the proposed patch constituted
"General maintenance."
All historical developers and contributors have n
Graham Percival a écrit :
According to
http://savannah.gnu.org/forum/forum.php?forum_id=5828
a push is precisely what we should do -- since git is a
decentralized source control system, that will upload all the
missing history.
Of course. Let's hope everybody who has pushed to Git between
them again (I am thinking of GDP and the frogs, in
particular).
I just pushed the following head to master:
Author: Neil Puttock 2009-05-28 21:10:33
Committer: John Mandereau 2009-06-02 15:17:02
Parent: 25a8f865167d709555d356df7df5c89b011b3670 (Remove undefined
'break-align-symbols v
John Mandereau a écrit :
I just pushed the following head to master:
BTW I advise all people with Git push access to pull master with
--rebase flag before pushing again his recent changes.
People who notice the shape of the history I pushed will understand the
reason :-/ Note that I didn&#
Jonathan Kulp a écrit :
I'd be especially keen to hear if someone has a better way to display
the directory structure of the sample project, as it takes up quite a
bit of space.
I'd recommend using `tree'.
Cheers,
John
___
lilypond-devel mailing l
Mark Polesky a écrit :
Why didn't this patch work?
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=269248a11ada074066deb061d64df70ee7b4deec
I changed \var{} to \code{} but it still shows up as \var{} in the
html.
http://lilypond.org/doc/v2.13/Documentation/user/lilypond/Overv
Mark Polesky a écrit :
Is the Hungarian-language news item on the lilypond.org hopmepage
supposed to be there? It seems a little odd. Better if it were
translated to English, I think.
It is lilypond.org news tradition to announce translation events in the
translated language.
Maybe the titl
Jonathan Kulp a écrit :
What I don't understand is how the permissions got jacked up in the
first place. I didn't do anything different this time than I usually
do. I've never had the permissions problem before. Maybe I put a
"sudo" in there inadvertently but I don't recall doing any sudos unt
Hi guys,
Graham Percival a écrit :
Eventually, I'd like to have
docs/
docs/web/
docs/learning/
docs/reference/
docs/devel/
docs/snippets/
docs/examples/ (maybe)
with the approporiate translation files in each subdir.
John, if you're reading this: don't worry, I'm going to do
Francisco Vila a écrit :
2009/6/6 Graham Percival :
Err... by "run GUB", I mean "generate sheet music using the
downloaded .exe".
GUB is the builder, and it builds the released binaries. You run the
builder or the released binary. I propose to call things by their
names.
Agreed. We
Graham Percival a écrit :
What's the problem with distributing the website source? I can't
imagine this being technically challenging, and I don't think
there's any security issues...?
And what about copyright? If we distribute the website, Han-Wen and Jan
should decide redistribution cond
Werner LEMBERG a écrit :
I just followed this link and it is checked successfully.
This is because I pushed fixes for those errors. Mark, thanks for the
report.
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/m
Francisco Vila a écrit :
This is driving me mad. I think that, with the new policy of
committing our own changes to input/lsr it is impossible to avoid
conflicts between lilypond/translation and master.
It's not impossible, but it is more difficult... :-/ more below.
Besides, frequent mer
Francisco Vila a écrit :
BTW is it possible that branches have diverged because of the
breakdown of savannah, and I am having conflicts despite of branches
having been merged recently? IIRC git told me exactly that but I
ignored it.
It's possible. Did you pull master with -r flag before changin
Graham Percival a écrit :
Despite that, I must admit that I misremembered the previous
discussion about the website. I thought we'd all agreed on
texi, but reading the discussion now, I see that opinions were all
over the map. :|
IIRC there was some consensus about writing some documents i
Graham Percival a écrit :
Hmm. I guess we could rename AU to "General Information" or
something like that?
What would be the form of that "General Information"? A manual or a
website? Renaming AU to something
else implies keeping a manual form, doesn't it? Even if you heavily
customize HTML
Graham Percival a écrit :
Whenever I reinstall
Linux, I always forget to install the international fonts. (and
those aren't checked by autogen.sh!)
There are several dependencies for the documentation that are not
checked by configure script. We may want to fix this by enforcing some
Le 13/06/2009 19:25, Federico Bruni a écrit :
I've read that page and started the first steps.
Dear Federico,
Sorry for the slightly delayed reply, and congratulations for your
involvement in translation of our (huge) documentation. Carl answered
your questions quite well; I'll apply your pa
Le 14/06/2009 01:33, Graham Percival a écrit :
Umm, I'm expecting to almost-completely rewrite the website in the
next few days. I'm really not certain that starting to
translating the website now is a good idea.
Tentative new website ready (i.e. start translating): late June.
If this ca
in the files that are actually translated.
> Anyway, the files I committed some days ago are not present in the
> tree on the web git repository (as far as I can see).
> I guess John Mandereau is supposed to do that, as he mentioned in a
> previous email.
> Probably he's waiting f
Hello Jean-Charles,
Le lundi 15 juin 2009 à 22:54 +0200, Jean-Charles Malahieude a écrit :
> It works well with a 8.64 gohstscript. I'm still upset because I
> don't understand the reason why.
I had problems with gs 8.63 on Fedora 9, I followed Graham's suggestion
on upgrading it to the same
Hi Francisco,
Le mercredi 17 juin 2009 à 11:38 +0200, Francisco Vila a écrit :
> John, if you finally own a Masters (congratulations!)
Err, my thesis is in a good shape but I have no idea when I'll get the
official results and diploma: I switched to a new University last year,
there might be some
Hi Francisco,
Le jeudi 18 juin 2009 à 12:17 +0200, Francisco Vila a écrit :
> Just curiosity, how do you make these commits after the merge, to
> appear in both branches?
I just push the same branch directly to both master and
lilypond/translation.
In the usual case, suppose I merged lilypond/tra
Le 13/06/2009 20:14, Graham Percival a écrit :
> To counter-act the "texi2html looks boring" idea, here's a new
> version:
> http://percival-music.ca/blogfiles/out/lilypond-general_1.html
You made the proof of concept of using texi2html to write a website in
Texinfo; this is nice and promising, I
Le dimanche 28 juin 2009 à 17:33 +0200, Francisco Vila a écrit :
> The current scheme of committishes on texidoc files makes hard to do
> this automatically, because languages can be in any order into the
> file. How can it be said what language it belongs? I suggest to mark
> the line with the lan
Le dimanche 05 juillet 2009 à 18:01 -0700, Patrick McCarty a écrit :
> On Sun, Jul 05, 2009 at 05:39:45PM -0700, Graham Percival wrote:
> > -dwarning-as-error
> > looks fine to me.
>
> I think Han-Wen suggested to enable this option for the entire
> regression test suite, so adding this option to
Le samedi 04 juillet 2009 à 01:58 -0700, Graham Percival a écrit :
> arpeggio* should have \\ as well. Also, they should also be
> matched with full words. In fact, 99% of the convert-ly rules
> need to match a complete word. According to Daniel Hulme,
> "\\octave\b" would work fine.
>
> 1) Co
009/7/7 Graham Percival :
> I'm not, but almost all updates are in the form
> \\oldCommand -> \\newCommand
>
> I suppose that somebody might have tried to speed up convert-ly
> processing by doing
> \\old -> \\new
> and leaving the "Command" out (thereby using one rule, instead of
> two rules), b
2009/7/8 Carl D. Sorensen :
> Such a function would ease the writing of *new* rules, which is what I think
> Graham's main emphasis is.
>
> I believe that it's clearly *not* worth it to fix old rules; there is *no*
> benefit to fixing old rules if they're not breaking. If they do break, we
> can f
2009/7/9 Graham Percival :
> Is anybody familiar with the monstrosity that is the
> makefiles/stepmake build system in LilyPond?
>
> I've split the essay away from LM 1, because it never belonged
> there, and the website redesing had a nice place for it on its
> own. I hacked up the GNUmakefile un
Sorry, I was still a bit asleep, my first reply was incomplete.
2009/7/9 John Mandereau :
> 2009/7/9 Graham Percival :
>> 1) Could you check Documentation/GNUmakefile,
>> Documentation/user/GNUmakefile, and
>> Documentation/essay/GNUmakefile?
>
> IMO, an .itely file t
2009/7/9 John Mandereau :
> WTM do you want to have one manual per directory? I agree it
> would make clearer which master .tely file each .itely files belongs
> to
For this purpose, we could just move .itely files into subdirs; it wasn't
possible when you suggested it during GDP
2009/7/9 Graham Percival :> On Thu, Jul 09, 2009
at 08:35:15AM +0200, John Mandereau wrote:
> Well, the website is current built with:
> texi2html -I=$(imagedir) -I=$(exampledir) --output=$(outdir) \
> --init-file=web-texi2html.init --split=section lilypond-general.texi
> so
2009/7/9 Maximilian Albert
> Hmm, I tried to run the regression tests via 'make check' (is that the
> right way to do it?)
No, see "Testing LilyPond" in the Contrib Guide or in Application
usage, section Install/build from source/compile (don't remember the
exact name).
> with the current git v
2009/7/9 Maximilian Albert :
> 'make doc' (which I initially thought generates the
> documentation) produces an error
Which error? If you can't fix it yourself, please report, including
the last 100 lines of make output and other log files as appropriate.
> and 'make web' only says "make: ***
>
2009/7/9 Patrick McCarty :
> So, are we keeping the Documentation/essay directory?
I'm against creating this directory right now, please junk (I'm at
Libre Software Meeting in
Nantes, France, where some WiFi access points block port 22, so I
can't do it right now)
and revert the commit unless some
2009/7/10 Graham Percival :
> Unless there's a totally unexpected deluge of help for the website
> from my recent plea on the -user list, I can't imagine it being
> ready for 2.14. And I can't recommend delaying 2.14 just for a
> new website.
There are a few technical bits too.
> That said, I s
Sorry, I still don't master Google webmail key bindings well :-(
2009/7/11 John Mandereau :
> work on bits of the translation infrastructure that have been dela lot
> delayed.
I meant "that have been delayed a lot".
Best,
John
_
2009/7/11 Carl Sorensen :
> Ahh -- there is a clue here that I hadn't noticed before. The comments in
> the code are different in the snippet from rhythms.itely and the doc
> output.
>
> That means that the snippet in rhythms.itely is *not* the one that is being
> compiled for the docs.
What are
2009/7/11 Neil Puttock :
> How about using a `try' block to import conditionally?
Alternatively, a conditional block based on testing sys.hexversion,
which is already used in lilypond-book, could help.
Cheers,
John
___
lilypond-devel mailing list
lily
2009/7/11 Carl Sorensen :
> The difference is two lines of comments. The one that is showing up in the
> docs is an older version than the one that is currently in rhythms.itely.
>
> Please note that the snippet is not an included file, but is actually part
> of the text in rhythms.itely. It's as
2009/7/11 Graham Percival :
> - unless we delay 2.14 by a month or two... or four or five... the
> translations won't be ready.
Let's give two weeks to update/translate new files marked with
priority 1, then let's consider the translations are ready to move to
the new website and are ready for th
2009/7/11 Graham Percival :
> Similiar stuff has happened to me, but since it involves the build
> process, I never bothered trying to track down the problem. I
> just do a make clean, make web-clean (that's probably doc-clean
> now), and regenerate everything.
>
> You could _try_ touching rhythms
source file changes, let make(1) handle it.
>>
>> I dropped it in my local copy, and make succeeded. But I have not pushed
>> the change to git, and won't. I don't have enough confidence that I know
>> the build process well to be sure I'm not breaking so
Le samedi 11 juillet 2009 à 03:13 -0700, Graham Percival a écrit :
> - the "website" is available in HTML, info, and pdf. If you type
> "info lilypond", you get the website. Package managers might
> create a lilypond-doc package consisting of the pdfs, or a local
> copy of the HTML, or what
Le mardi 14 juillet 2009 à 23:27 -0700, Graham Percival a écrit :
> On Tue, Jul 14, 2009 at 04:23:52PM +0200, Jean-Charles Malahieude wrote:
> > I'm going back to updating the "web" branch.
>
> I'm never certain how much translators know about the other
> development stuff... just checking, you *d
Le lundi 13 juillet 2009 à 10:57 +0200, Jan Nieuwenhuizen a écrit :
> I realised it would be nice if texi2html would copy any @ignore @end
> ignore blocks to html comments so that
> you can easily check if the website is up to date.
It would be even simpler if texi2html could even copy every comm
Le lundi 13 juillet 2009 à 06:07 -0600, Carl Sorensen a écrit :
> So, in order to not have broken documentation, I need to eliminate old file
> referenes, and old in-line snippets as well.
>
> I guess I should just edit all of the Documentation/*/user/rhythms.itely and
> delete the parts that have
Le mercredi 15 juillet 2009 à 07:43 -0600, Carl Sorensen a écrit :
> On 7/14/09 3:57 PM, "n.putt...@gmail.com" wrote:
> > http://codereview.appspot.com/88155/diff/95/1147#newcode69
> > Line 69: section 1.2.4 Beams, for more information.
> > Is it possible to use @ruser{} here?
>
> I'm not sure.
Le mardi 14 juillet 2009 à 16:21 -0600, Carl Sorensen a écrit :
> Hmm -- I read through the CG and missed it. Now that I know what I'm
> looking for, I see where it is. I'll add something to the CG.
Thanks. The general problem when I write instructions in the CG (besides
the fact that I still ha
Le samedi 11 juillet 2009 à 03:21 -0700, Graham Percival a écrit :
> Here's my proposal for the source/makefile view of documentation.
> (this is the big argument one)
...and here is my big reply :-P
> My understanding is that linking between texinfo manuals is easier
> if the main files are in
101 - 200 of 1573 matches
Mail list logo
