• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
[OT] Re: Line-number references wrong by several lines
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OT] Re: Line-number references wrong by several lines


  • Subject: [OT] Re: Line-number references wrong by several lines
  • From: Alastair Houghton <email@hidden>
  • Date: Sun, 3 Feb 2008 18:47:26 +0000

On 3 Feb 2008, at 18:25, Jeffrey Oleander wrote:

Alastair Houghton <email@hidden> wrote:
On 2008-02-03 at 04:32, Jeffrey Oleander wrote:
Why not treat them as line-feeds and carriage-returns?

Because it isn't practical in a text editor. Imagine

ABCDEF\rGHIJKL

which would render with the GHIJKL over-struck on ABCDEF.

Which is exactly what it was meant to achieve. Would you prefer to eliminate that capability?

In a text editor, yes, certainly. It's confusing and it isn't clear how you'd differentiate between e.g.


  ABCDEF\rGHIJKL
  ABC\rGHIDEF\r   JKL
  A\bGB\bHC\bID\bJE\bKF\bL

if you're going to try to interpret the control sequences literally for display. Much better just to display the control characters, in which case you need to make a guess as to which line ending convention is in use, but that's about all (and you only do so for display... the data in memory doesn't need to be altered at all).

Now the user clicks between A and B.  Where should the
cursor go?
Or they click to the right of F.  Where does it go now?

In the first example, between the A and B and between the G and H. In the second case, it should go after the F.

I meant in memory, as I'm sure you realised. And even on-screen it might not be so obvious, e.g. if the font is not fixed-width.


1. Keep the characters that were in the original file,
and guess which convention we're using (or let the
user specify).  The advantage is that loading and
saving a file won't change the file.  It might not
look right though (for instance, it's quite common
to see ^M
characters in Emacs, which uses this solution,
when a UNIX format text file has been edited
using an inappropriate editor on a PC).

Yes, vi and vim display the carriage-returns that way.

Other control characters too, as does Emacs. It's the only sane way to do this, for the reasons I gave before.


It's definitely the best way to do things for an *editor*. Normally you'd want to see the control codes, rather than their effect.

Anyway, this is headed off-topic now. My point was solely that we don't want Xcode to do what you suggest, and that what Steve suggested isn't right (for Xcode) either. IMHO Emacs is a good model to follow here; it even provides a way for the file you're loading to specify its own line ending, tab width, etc...

Kind regards,

Alastair.

--
http://alastairs-place.net



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Line-number references wrong by several lines (From: Jeffrey Oleander <email@hidden>)

  • Prev by Date: Re: Line-number references wrong by several lines
  • Next by Date: Creating a new project in Xcode 3.0
  • Previous by thread: Re: Line-number references wrong by several lines
  • Next by thread: Re: Line-number references wrong by several lines
  • Index(es):
    • Date
    • Thread