Re: Line-number references wrong by several lines
Re: Line-number references wrong by several lines
- Subject: Re: Line-number references wrong by several lines
- From: Jeffrey Oleander <email@hidden>
- Date: Sun, 3 Feb 2008 10:25:59 -0800 (PST)
> 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? Then again, who,
other than an APL programmer, needs such a capability,
anymore? We can do such things, now, simply by adding
characters to our set, and have the glyphs be automagically
combined appropriately. So, I readily concede that this is
not a vital ability for a source code editor.
> 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
believe the tougher question to answer is, if the user then
enters some text where should it go in the memory or file
as opposed to on-screen? There's a break-down between the
power of the editor and the desire for WYSIWYG, so this is
where you use a modal switch or side-by-side views.
> Or maybe they click and drag over DEF. What is selected?
> How is that displayed?
> There are two good ways to deal with the line ending
> problem:
> 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.
QUED/M and Nisus Writer used to give options to cover which
should be considered the line-end on open and whether to
retain the original or save in a different, specified
format.
> 2. Try to keep the lines the way the file probably
> intends them, using an algorithm like Steve's.
> The advantage is that you see all the line
> endings, even ones that aren't in the "right" format.
> Option 1 is probably best for a text editor, since you
> don't really want it to change things if it doesn't have
> to. Option 2 is probably best if you're reading a text
> file from code, e.g. to read settings or something.
Option 2 is probably best for people who don't know the
issues thoroughly, but I like giving people the ability to
do what they want to do, including a convenient way to
convert. The current set-up of Xcode does a fairly good
job at that, though there's plenty of room for coming
closer to perfection, I suppose.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
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