>> What do you think about converting all tabs in the .mf files to
>> spaces?
>
> I consider this a good idea. [...]
OK, so I will do this within the next couple of days.
Werner
>> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
>> branch.
>
> Ugh, that's giving me a nice set of conflicts.
Sorry for that.
Werner
Am Dienstag, den 25.02.2020, 11:13 +0100 schrieb Werner LEMBERG:
> Folks,
>
>
> something that can be easily missed while doing reviews with Rietveld:
> Since a long time we avoid tabs if possible.
>
>
> Werner
>
>
> PS: I've cleaned up `configu
On Feb 25, 2020, at 05:29, Werner LEMBERG wrote:
>
> What do you think about converting all tabs in the .mf files to
> spaces? If you agree, I would apply this to the staging.
I don't usually work in that domain, so SGTM.
—
Dan
Werner LEMBERG wrote
> What do you think about converting all tabs in the .mf files to
> spaces?
I consider this a good idea.
On the one hand, we are encouraged /not/ to use tabs. On the other hand,
however, especially mf files are full of them and I've often wondered how to
>> PPS: I see that we have a file `.dir-locals.el` in the git
>> repository; doesn't its contents contradict our tabs policy?
>
> No, it implements it.
Ah, ok. Thanks for the explanation.
> Yes, does not read well to human readers. Maybe one should tack on
Werner LEMBERG writes:
> Folks,
>
>
> something that can be easily missed while doing reviews with Rietveld:
> Since a long time we avoid tabs if possible.
>
>
> Werner
>
>
> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
> b
What do you think about converting all tabs in the .mf files to
spaces? If you agree, I would apply this to the staging.
Werner
Folks,
something that can be easily missed while doing reviews with Rietveld:
Since a long time we avoid tabs if possible.
Werner
PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
branch.
PPS: I see that we have a file `.dir-locals.el` in the git repos
On 2012/09/26 06:32:15, dak wrote:
will do.
thanks, and LGTM
http://codereview.appspot.com/6551050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ry for the oversight, will do.
Description:
Set up indent-tabs-mode in lexer.ll and parser.yy
indent-tabs-mode has been switched off for C++ files with
directory-local variables.
However, for lack of working better indentation modes that cooperate
well with Bison and Flex files, lexer.ll and par
Do i understand correctly that this is something for Emacs' sake?
If so, please add this information to the commit message, so that
non-emacs people like me will immediately know what's it about.
thanks,
Janek
http://codereview.appspot.com/6551050/
__
lgtm
http://codereview.appspot.com/6551050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Mon, Dec 19, 2011 at 08:04:49PM -0500, Michael Welsh Duggan wrote:
> I seem to recall that spaces were going to be used instead of tabs
> wherever possible in source files. Is there a reason that parser.yy
> uses tabs instead of spaces?
I didn't run astyle on parser.yy because
I seem to recall that spaces were going to be used instead of tabs
wherever possible in source files. Is there a reason that parser.yy
uses tabs instead of spaces?
--
Michael Welsh Duggan
(m...@md5i.com)
___
lilypond-devel mailing list
lilypond
Reviewers: ,
Message:
I have no clue why this works, but I think it works and solves
Federico's problem. Hopefully someone can have a look at it and suggest
a better way to tackle this.
Cheers,
MS
Description:
Kludgy way to get the glissando engraver working with tabs.
Please review th
On Wed, Jul 29, 2009 at 11:13:52PM +0100, Neil Puttock wrote:
> 2009/7/29 Graham Percival :
>
> > 6) If we want to use this, the patch needs to be examined
> > carefully. There aren't many problems, but we definitely
> > shouldn't apply it blindly. (we'd have lost that good comment
> > otherwis
2009/7/29 Graham Percival :
> Let's tackle the cc files first. I tried running it on everything
> lily/*.cc, and ended up with a 126K diff.
>
> 1) many changes were simply moving */ to the left by 1 char.
> That's fine.
I've amended these myself a few times, but it's just occurred to me
the ex
2009/7/29 Graham Percival :
> On Wed, Jul 29, 2009 at 10:12:11AM +0200, Francisco Vila wrote:
>> $ emacs -batch vertically-spaced-context-engraver.cc --eval
>> '(indent-region (point-min) (point-max) nil)' -f save-buffer
>>
>> (tested on cc files, seems to leave them as they currently are)
> Is th
On Wed, Jul 29, 2009 at 10:12:11AM +0200, Francisco Vila wrote:
> Those two copyPasteable lines do work.
Thanks, added to the CG.
> $ emacs -batch vertically-spaced-context-engraver.cc --eval
> '(indent-region (point-min) (point-max) nil)' -f save-buffer
>
> (tested on cc files, seems to leave t
Those two copyPasteable lines do work.
2009/7/29 Francisco Vila :
>> If somebody could post command-line copy&paste for:
>> 1) apply texinfo-all-menus-update to a file
$ emacs -batch my-texinfo-file.tely -f texinfo-all-menus-update -f save-buffer
(tested)
or possibly
$ emacs -batch my-texinfo
2009/7/29 Graham Percival :
> As an aside, could somebody (Francisco?) post a copy&pasteable
> line to use emacs for the source code formatting? Yes, I could
> read the emacs man page and try to figure out how to use the emacs
> -batch command myself, but there's other things that are more
> impor
ever actually knew
> > what I was talking about. :)
>
> Right - that is why in general I don't want to oppose people who take
> initiatives (like banning tabs), but in this particular case, I am not
> sure if the heat is worth the light.
Well, the whole thing began be
ypond programming", but I never actually knew
> what I was talking about. :)
Right - that is why in general I don't want to oppose people who take
initiatives (like banning tabs), but in this particular case, I am not
sure if the heat is worth the light.
--
Han-Wen Nienhuys - han...@xs
On Tue, Jul 28, 2009 at 03:56:53PM +, Han-Wen Nienhuys wrote:
> On a larger scale, I am somewhat disappointed that a lot of the latest
> lilypond efforts seem to be centered around janitorial work. While
> janitorial work is often useful and a good way to introduce yourself
> to a code base,
oo_l_ for every pointer.
>> I don't see why we should not allow ourselves to be stricter wrt to
>> tabs as well.
>
> For one, I would rather like to see us being more standard rather
> than less. Second, the first time this started, people were discussing
> creating codi
r :-) If I could go back and switch to autotools,
I would have had to sacrifice valuable hacking time [at least 20min
per night], but I would possibly gain John's eternal love ;-)
> I don't see why we should not allow ourselves to be stricter wrt to
> tabs as well.
For one, I would
>>>>> "Carl" == Carl Sorensen writes:
Carl> On 7/25/09 10:58 AM, "Mark Polesky"
Carl> wrote:
>>
>>
>> ...tabs in the source code...
>>
>> Werner Lemberg wrote:
>>> I dislike them, too, but there are many editor
compared to GNU, and I think we generally had a tendency
to have ever stricter coding guidelines. For example, we have
underscores on class data members.
I don't see why we should not allow ourselves to be stricter wrt to
tabs as well.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://w
careful.
>;; Your init file should contain only one such instance.
>;; If there is more than one, they won't work right.
> '(indent-tabs-mode nil))
>
> Documentation:
> *Indentation can insert tabs if this is non-nil.
That won't work, at least not
Le 27 juil. 09 à 17:16, Han-Wen Nienhuys a écrit :
On Sat, Jul 25, 2009 at 5:30 AM, Graham
Percival wrote:
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs
On Sat, Jul 25, 2009 at 5:30 AM, Graham
Percival wrote:
> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
>> Thanks, Neil. My editor does confusing things with tabs.
>> I hate them. Who would object if I just started running
>> tabs->spaces on the source docs
There's a file scripts/auxiliar/fixcc.py which claims to
"nitpick lily's c++ code". If that script works, let's use it.
If it's broken, let's either fix it or junk it.
I must admit that there's unfortunately no "fixscm.py" file, which
is
Le samedi 25 juillet 2009 à 09:58 -0700, Mark Polesky a écrit :
> But even in such cases, as long as my tab-width matches the
> tab-widths in the source, tabs2spaces should be fine. Is it
> correct to say that git (or savannah) translates all tabs to 8
> spaces without exception?
;sending a patch to emacs-devel".
>>
>> The current standard is to let tabs and spaces be handled as
>> emacs handles them.
>
> Oh, is that something that could ever happen, realistically?
In the GNU world, yes. emacs is the GNU standard programming editor.
In *my* real wor
On 25 Jul 2009, at 19:39, Patrick McCarty wrote:
One thing you could do right now, without awaiting approval, is to
check for lines that have tabs *after* spaces at the beginning. These
should be converted to tabs *followed* by spaces.
This is not correct, as if tabs are set to 8 spaces, 2
Carl Sorensen wrote:
> No, Jan was not in favor of it unless it became a standard for
> GNU coding. Hence the comment on "first making it a standard"
> (i.e., a GNU standard) and "sending a patch to emacs-devel".
>
> The current standard is to let tabs and s
On Sat, Jul 25, 2009 at 09:58:26AM -0700, Mark Polesky wrote:
>
> Also, can we list all of the possible situations where we need to
> retain tabs? Ian mentioned .make files; the last time this came up
> Patrick McCarty mentioned something about demarcating syllables in
> lyrics
On 7/25/09 10:58 AM, "Mark Polesky" wrote:
>
>
> ...tabs in the source code...
>
> Werner Lemberg wrote:
>> I dislike them, too, but there are many editors which handle
>> them just fine. I don't see a problem here.
>
> But would you
Joe Neeman wrote:
> I like spaces just fine, but I'd prefer it if you could hold off
> on this for a little while. I have a big patch that I'd like to
> merge and I'm not so keen on resolving a bunch of whitespace
> conflicts...
Okay, I'll make a note: I'll wait for Han-Wen, Jan, and Joe.
Thanks
On Sat, 2009-07-25 at 09:58 -0700, Mark Polesky wrote:
> ...tabs in the source code...
>
> Werner Lemberg wrote:
> > I dislike them, too, but there are many editors which handle
> > them just fine. I don't see a problem here.
>
> But would you be *opposed*
...tabs in the source code...
Werner Lemberg wrote:
> I dislike them, too, but there are many editors which handle
> them just fine. I don't see a problem here.
But would you be *opposed* to a strict no-tab rule?
Carl Sorensen wrote:
> The last communication we had about i
On 7/24/09 11:32 PM, "Mark Polesky" wrote:
>
>
> Graham Percival wrote:
>
>> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
>>> Thanks, Neil. My editor does confusing things with tabs.
>>> I hate them. Who would object if I just
>> Thanks, Neil. My editor does confusing things with tabs.
Then use a different editor.
>> I hate them.
I dislike them, too, but there are many editors which handle them just
fine. I don't see a problem here.
Werner
_
Hi Graham,
Graham Percival wrote:
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs->spaces on the source docs? I think we should have
a strict no-tabs rule.
On Fri, Jul 24, 2009 at 10:30:30PM -0700, Graham Percival wrote:
> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> > Thanks, Neil. My editor does confusing things with tabs.
> > I hate them. Who would object if I just started running
> > tabs->spaces on the
Graham Percival wrote:
> On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> > Thanks, Neil. My editor does confusing things with tabs.
> > I hate them. Who would object if I just started running
> > tabs->spaces on the source docs? I think we should have
&
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
> Thanks, Neil. My editor does confusing things with tabs.
> I hate them. Who would object if I just started running
> tabs->spaces on the source docs? I think we should have
> a strict no-tabs rule. And I'm in
Ralph Little <[EMAIL PROTECTED]> writes:
> Hi,
> Ah, sorry, I should have made myself clearer - I meant in Lilypond
> source code. :D
>
> 2 spaces it is..
2 spaces, but "C-x h M-x tabify"ed.
nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.
.
Do we use tabs in Lilypond code, or 2 spaces?
In the documentation, we use two spaces. That's mentioned in the
README for doc writers. For your own personal stuff, use whatever you
want. :)
Cheers,
- Graham
___
lilypond-devel mailing
Ralph Little wrote:
I have looked at the GNU coding style recommendations, but could not see
a preference for the use of tab characters in code.
Do we use tabs in Lilypond code, or 2 spaces?
In the documentation, we use two spaces. That's mentioned in the README
for doc writers. For
Hi,
I have looked at the GNU coding style recommendations, but could not see
a preference for the use of tab characters in code.
Do we use tabs in Lilypond code, or 2 spaces?
Regards,
Ralph
___
lilypond-devel mailing list
lilypond-devel@gnu.org
[EMAIL PROTECTED] writes:
> After the introduction of guitar tabs we should ensure that everything works
>
> - On even number of staff lines
> - When Staff-space != 1
>
> Especially there are (crucial) problems with rests.
Before 1.6 -- there should also be documentation. A
After the introduction of guitar tabs we should ensure that everything works
- On even number of staff lines
- When Staff-space != 1
Especially there are (crucial) problems with rests.
-Rune
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http
54 matches
Mail list logo
