And of course, you can already see your current line number on the 
status bar...

Michael Besosa wrote:
> Of course compilers report errors by line number (what else could they do?).
> But there's already a way to GO to a line number. That's all I find I,
> personally, need. Anyway, the real point is, I'd prefer not to be forced to
> display line numbers to get an essentially unrelated and very convenient
> feature (drag to select a range of lines). That seems like a curious design
> decision.
> 
> "Paul Bradshaw" <[EMAIL PROTECTED]> wrote in message
> aghool$am3$[EMAIL PROTECTED]">news:aghool$am3$[EMAIL PROTECTED]...
> 
>>The compiler (especially when using an external ant build system as we do,
>>not always from within an IDE) reports line numbers.  Not every developer
> 
> on
> 
>>a project uses the same IDE (or any IDE).  Line numbers are invaluable for
>>communicating between developers sitting at different terminals.  I use
> 
> them
> 
>>all the time.  Just FYI.
>>
>>"Michael Besosa" <[EMAIL PROTECTED]> wrote in message
>>agh8er$jf0$[EMAIL PROTECTED]">news:agh8er$jf0$[EMAIL PROTECTED]...
>>
>>>That's not a bad idea. But... My complaint with line numbering is that
>>
> you
> 
>>>can't drag to select lines (which I use heavily) without line numbers
>>
>>turned
>>
>>>on. Actually, for the life of me, I can't really see why, in a modern
>>
> IDE,
> 
>>>you need to see line numbers at all. You don't need them to find code.
>>
> You
> 
>>>don't need them to see which line your cursor is on (if you need to
>>
> know).
> 
>>>Really, what's the point? I would have them turned off if it didn't mean
>>>giving up dragging to select lines. Of course, if you could drag in the
>>>margin occupied by the icons, inserting breakpoints would probably have
>>
> to
> 
>>>be marginally less convenient. That wouldn't bother me, because, for me,
>>>selecting lines is a far more common operation than changing
>>
> breakpoints.
> 
>>>But I can see that others might not agree.
>>>
>>>One thing that COULD be changed easily would be to click on the line
>>
>>number
>>
>>>to select the entire line. Right now, you have to click AND DRAG to
>>
> select
> 
>>>even a single line. That's counter to the way this feature is usually
>>>implemented. In fact, as I think of it, it would be nice if multiple
>>
>>clicks
>>
>>>on the same line number behaved in a way similar to CTRL-Q (is that
>>
> right?
> 
>>I
>>
>>>have it remapped), selecting first the line, then on successive clicks
>>>within the double-click threshold, all the lines in each of the
>>
> enclosing
> 
>>>blocks.
>>>
>>>"Paul Ruane" <[EMAIL PROTECTED]> wrote in message
>>>news:[EMAIL PROTECTED]...
>>>
>>>>I have line numbering swiched on despite losing a fair few pixels of
>>>
>>>valuable screen real-estate.  I then realised that there is little
>>
> reason
> 
>>to
>>
>>>not combine the line numbering with the breakpoint/icon bar beside it.
>>>Here's what I mean:
>>>
>>>>o With line numbers off, the breakpoint bar appears as it does now,
>>>
>>>showing breakpoints, bookmarks etc.
>>>
>>>>o With line numbers on, the breakpoint bar is widened to accomodate
>>>
> the
> 
>>>numbering and appears as wide as the line numbering bar does now.
>>>
>>>>    - Line numbers are shown in the widened breakpoint bar.
>>>>    - Any icons are drawn over/instead of the numbering for that line.
>>>
>>>There's enough uniconed lines surrounding to easily work out the line
>>>number.
>>>
>>>>    - Alternatively a) the icons could be overlaid semi-transparently
>>>
> or
> 
>>>b) the line number could be drawn whole beside the icon but in a smaller
>>>font.
>>>
>>>>I think this would give the benefits of line numbering without the
>>>
> space
> 
>>>penalty.
>>>
>>>>Paul.
>>>>
>>>>
>>>>--
>>>>
>>>>This e-mail may contain confidential and/or privileged information. If
>>>
>>you
>>
>>>are not the intended recipient (or have received this e-mail in error)
>>>please notify the sender immediately and destroy this e-mail. Any
>>>unauthorized copying, disclosure or distribution of the material in this
>>>e-mail is strictly forbidden.
>>>
>>>>
>>>
>>
> 
> 

_______________________________________________
Eap-features mailing list
[EMAIL PROTECTED]
http://lists.jetbrains.com/mailman/listinfo/eap-features

Reply via email to