On Mon, Nov 2, 2009 at 1:39 PM, Bertalan Fodor (LilyPondTool)
wrote:
> Patrick McCarty wrote:
>> Okay, that means mbrtowc() is supported and the preprocessor macro
>> HAVE_MBRTOWC is enabled. So my guess was wrong. :-(
>>
>> I plan on removing this function (due to the FIXME) and use a simpler
>
Patrick McCarty wrote:
On 2009-11-02, Graham Percival wrote:
On Mon, Nov 02, 2009 at 01:07:48AM -0800, Patrick McCarty wrote:
The second case is much more likely. Graham, I don't want to bug you
with this, but would you mind checking the log for mingw::lilypond to
see if configure dete
On 2009-11-02, Graham Percival wrote:
> On Mon, Nov 02, 2009 at 09:06:46AM -0800, Patrick McCarty wrote:
> > On 2009-11-02, Graham Percival wrote:
> > > I have
> > > ac_cv_func_mbrtowc=yes
> > > ac_cv_search_mbrtowc='none required'
> > > and also
> > > #define HAVE_MBRTOWC 1
> > >
> > > Dunn
On Mon, Nov 02, 2009 at 09:06:46AM -0800, Patrick McCarty wrote:
> On 2009-11-02, Graham Percival wrote:
> > I have
> > ac_cv_func_mbrtowc=yes
> > ac_cv_search_mbrtowc='none required'
> > and also
> > #define HAVE_MBRTOWC 1
> >
> > Dunno what that second line means.
>
> Okay, that means mbr
On 2009-11-02, Graham Percival wrote:
> On Mon, Nov 02, 2009 at 01:07:48AM -0800, Patrick McCarty wrote:
> > The second case is much more likely. Graham, I don't want to bug you
> > with this, but would you mind checking the log for mingw::lilypond to
> > see if configure detects the mbrtowc() fun
On Mon, Nov 02, 2009 at 01:07:48AM -0800, Patrick McCarty wrote:
> The second case is much more likely. Graham, I don't want to bug you
> with this, but would you mind checking the log for mingw::lilypond to
> see if configure detects the mbrtowc() function? On my Linux system,
> the output is
>
On 2009-11-02, Bertalan Fodor (LilyPondTool) wrote:
> Patrick McCarty wrote:
> >On 2009-11-01, Bertalan Fodor (LilyPondTool) wrote:
> >>> 3) UTF-8 characters. In UTF-8 locales, terminals need to know about
> >>> the byte offset, so I am using the character count to specify this
> >>> offset. An e
Patrick McCarty wrote:
On 2009-11-01, Bertalan Fodor (LilyPondTool) wrote:
3) UTF-8 characters. In UTF-8 locales, terminals need to know about
the byte offset, so I am using the character count to specify this
offset. An example would be "3:11:10".
The third case is arguably misleading,
On 2009-11-01, Bertalan Fodor (LilyPondTool) wrote:
>
> > 3) UTF-8 characters. In UTF-8 locales, terminals need to know about
> > the byte offset, so I am using the character count to specify this
> > offset. An example would be "3:11:10".
> >
> >The third case is arguably misleading, so mayb
3) UTF-8 characters. In UTF-8 locales, terminals need to know about
the byte offset, so I am using the character count to specify this
offset. An example would be "3:11:10".
The third case is arguably misleading, so maybe it should be changed
to use the "3:10:10" instead. I am okay wit
How is the tab width determined? In my case, it was always 8, so it's
superfluous I think. And also IMHO there's no sense in differentiating
character & byte offset. They are misleading. I'd propose keeping only
the character offset, which does not take tab width into account, but
correctly
On 2009.10.29., at 22:12, Patrick McCarty wrote:
It *should* have an effect. But if I'm thinking about this correctly,
there will still be an off-by-one error in the character/column
counts, because my commit only affects the value of the character
count when non-ASCII characters are found.
I
On 2009-10-29, Harmath Dénes wrote:
> On 2009.10.29., at 22:12, Patrick McCarty wrote:
> >It *should* have an effect. But if I'm thinking about this correctly,
> >there will still be an off-by-one error in the character/column
> >counts, because my commit only affects the value of the character
>
2009/10/29 Valentin Villenave :
> 2009/10/29 Harmath Dénes :
>> No, the two are very different.
>> In http://code.google.com/p/lilypond/issues/detail?id=887, the _filename_
>> part of the URIs is wrong because of non-ASCII _filenames_.
>> In this bug (http://article.gmane.org/gmane.comp.gnu.lilypon
2009/10/29 Harmath Dénes :
> No, the two are very different.
> In http://code.google.com/p/lilypond/issues/detail?id=887, the _filename_
> part of the URIs is wrong because of non-ASCII _filenames_.
> In this bug (http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/16097),
> the _column position_
2009/10/27 Patrick McCarty :
> Valentin, can you add this to the tracker? The subject of this thread
> is okay for an issue summary.
Does http://code.google.com/p/lilypond/issues/detail?id=887 cover it?
I haven't mentioned the weird position oddity.
Cheers,
Valentin
___
On 2009-10-27, Harmath Dénes wrote:
> This bug is only reproducible under Windows.
Okay, I see that now. Sorry for the initial misunderstanding.
> (It is also important that you set the file encoding to UTF-8, but
> that is satisfied here.)
Okay.
> The positions in the URL are 3:11:11, both wi
On 2009-10-26, Patrick McCarty wrote:
> On 2009-10-01, Harmath Dénes wrote:
> > On Windows platform only (where the default encoding is not UTF-8),
> > non-ASCII characters in a source line shift the subsequent PDF
> > point-and-click link column positions in that line by 1. Example:
> >
> > %{ á
On 2009-10-01, Harmath Dénes wrote:
> On Windows platform only (where the default encoding is not UTF-8),
> non-ASCII characters in a source line shift the subsequent PDF
> point-and-click link column positions in that line by 1. Example:
>
> %{ á %} { a }
>
> The link of the note 'a' points to
On Windows platform only (where the default encoding is not UTF-8), non-ASCII
characters in a source line shift the subsequent PDF point-and-click link column
positions in that line by 1.
Example:
%{ á %} { a }
The link of the note 'a' points to the space after the 'a' (column 11), not to
it (col
20 matches
Mail list logo
