bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: point and click implementation


From: David Kastrup
Subject: Re: point and click implementation
Date: Sun, 14 Apr 2013 16:21:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

"Phil Holmes" <address@hidden> writes:

> The lilypad delivered with 2.17.16 is now updated to be the one in
> GitHub. I've got an updated version on my PC that supports the Find
> function better - the found string is highlighted and the window
> scrolls to the string that's been found.  I'll likely include this in
> the next release and mark
> http://code.google.com/p/lilypond/issues/detail?id=534 as
> fixed. Please open a new tracker for the other enhancement requests -
> I think it would be best to have one request per issue, since some are
> relatively simple and some not so.

Could you doublecheck that the region is not off-by-one?  The textedit
links have changed the column definition with

<URL:http://code.google.com/p/lilypond/issues/detail?id=2172>

and I quote its (quite verbose) commit message:

commit 314587c0714437b058c04173d81ad79db7452e73
Author: David Kastrup <address@hidden>
Date:   Thu Dec 13 11:53:02 2012 +0100

    Issue 2172: Get line and column numbers right.
    
    This uses 1-based columns on all error output, as is the standard for
    GNU programs.  It also flags version errors as being for line 1
    instead of line 0 since the latter confuses Emacs' compilation mode.
    
    The same column convention is used for point-and-click column numbers
    in textedit:// URIs.  In contrast, the byte offsets into a line (also
    in those URIs) are retained 0-based.
    
    For point-and-click, this yields the correct results when using the
    definitions for emacs and gvim in scm/editor.scm, the editors
    configured to interpret the column number.
    
    It is to be expected that Lilypond-specific shells (like Frescobaldi
    called via Okular for point-and-click) have specialized on the
    previous wrong behavior and will now exhibit the kind of one-off
    behavior that non-LilyPond specific programs did previously when
    encountering the error messages.
    
    I don't see a good migration strategy for those except possibly
    looking for the version number of LilyPond and deciding whether to do
    one-off calculations depending on that.


Obviously, if Lilypad is shipped with LilyPond, depending on whether it
uses the "column number" (changed) or "byte offset" (unchanged) field of
the textedit URIs, it will need updating if this has not already
happened.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]