On Mon, Nov 2, 2009 at 1:39 PM, Bertalan Fodor (LilyPondTool)
lilypondt...@organum.hu 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
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 example would
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, 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() function?
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 mbrtowc() is
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
Dunno what that second line
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
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
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
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 with
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,
2009/10/27 Patrick McCarty pnor...@gmail.com:
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
2009/10/29 Harmath Dénes harmathde...@gmail.com:
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
2009/10/29 Valentin Villenave v.villen...@gmail.com:
2009/10/29 Harmath Dénes harmathde...@gmail.com:
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
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
count
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 with
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 the
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:
%{ á %} { a }
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
19 matches
Mail list logo
