Home » Language IDEs » C / C++ IDE (CDT) » LPEX indentation
| LPEX indentation [message #17417] |
Mon, 11 February 2002 15:39  |
Eclipse User |
|
|
|
When I open a C/C++ file in Eclipse 2.0 01/25/2002 build, all tabs in
the file are shown incorrectly. (This also happens in 1.0 IIRC).
If the "Expand tab characters" setting is checked, the existing tabs are
shows as 8 space tabs, even though I have my tab increment set to 4.
If the "Expand tab characters" setting is unchecked, the first tab is
shown as a single space, and the others follow my tab position and tab
increment settings.
Newly typed code seems to appear OK, but if I go into the settings and
toggle the "Expand tab characters" check box, hitting Apply after each
change, the code changes quite significantly.
Has anyone else seen this behavior? Am I missing something, or is this a
bug? If the latter, I'll be happy to submit a bug report for it.
Thanks,
Randy
--
Randy Coulman
Senior Software Engineer
Key Technology, Inc.
RCoulman@keyww.com
|
|
|
| Re: LPEX indentation [message #17434 is a reply to message #17417] |
Mon, 11 February 2002 16:42  |
| Eclipse User |
|
|
|
Originally posted by: adrianstoristeanu.sympatico.ca
Randy,
Hard tabs ('u\0009') are always interpreted by LPEX as
every-8-characters positions. The tab positions you define in the
preference pages merely position the cursor (and, by default, insert
space characters up to that position when you edit the file).
A previous implementation of the LPEX editor used to expand hard tabs
according to the user settings - we ran into many usability problems,
with users editing files created on other platforms and having the
indentation messed by the various tab settings on each. Granted, a
'detab' command would be nice, to allow one to restore the file to the
indentation settings on its originating platform ('detab' it's on the
to-do list).
Here's LPEX's credo on the tabs issue, from the developer who
implemented it:
It is important to keep the concept of tab stops and tab characters
completely separate. They have different histories and different kinds
of programmers use them.
There are many column-oriented programming languages (COBOL, RPG) which
don't allow tab characters. When using an editor to work with these
programming languages, tab stops are valuable. By assigning tab stops
to special columns, users can navigate easily within a line. Other
languages are free format (C, Java).
Users make up their own formatting rules. Here it can also be useful to
set tab stops for indentation levels, comment positions, etc. Tab
characters, on the other hand, come from the UNIX world. Back then when
preserving storage space was important, a tab character could be used
instead of spaces. A tab character is expanded to 8 spaces. UNIX C
compilers and UNIX editors expand a tab character to 8 spaces. Any
legacy code that was written using tab characters was written with an
editor that expanded the tab character to 8 spaces. If we interpret a
tab character as anything other than 8 spaces, then the user will not
see the legacy code as it was written. If the user writes new code with
tab characters that are not expanded to 8 spaces, then other editors and
compilers will not see the new code as it
was written. Best advice seems to be to stay away from tab characters
altogether, but if you do come across them, expand them to 8 spaces. As
for the implementation of tab characters in the old version of LPEX, it
is just wrong.
Randy Coulman wrote:
>
> When I open a C/C++ file in Eclipse 2.0 01/25/2002 build, all tabs in
> the file are shown incorrectly. (This also happens in 1.0 IIRC).
>
> If the "Expand tab characters" setting is checked, the existing tabs are
> shows as 8 space tabs, even though I have my tab increment set to 4.
>
> If the "Expand tab characters" setting is unchecked, the first tab is
> shown as a single space, and the others follow my tab position and tab
> increment settings.
>
> Newly typed code seems to appear OK, but if I go into the settings and
> toggle the "Expand tab characters" check box, hitting Apply after each
> change, the code changes quite significantly.
>
> Has anyone else seen this behavior? Am I missing something, or is this a
> bug? If the latter, I'll be happy to submit a bug report for it.
>
> Thanks,
> Randy
> --
> Randy Coulman
> Senior Software Engineer
> Key Technology, Inc.
> RCoulman@keyww.com
|
|
|
| Re: LPEX indentation [message #17438 is a reply to message #17434] |
Mon, 11 February 2002 17:34 |
| Eclipse User |
|
|
|
Thanks for the quick and thorough response. I don't think I agree with
it, but I appreciate it.
Most editors I've used have a setting that says 1 TAB = x spaces. Files
with tabs show those embedded tabs as x spaces. To me, this makes
sense. If I'm working with legacy code that uses 8-space tabs, then I
will set my editor to use those settings. I'm not. I work with
not-so-legacy code that was written with editors that have configurable
tab widths.
I've certainly heard the suggestion to not use tab characters before.
My thought on the matter is that, if I've got all my tools configured to
use the same tab width, then real tab characters are not an issue. This
is the first programmer's editor I've come across that didn't allow me
to configure things that way.
>
> A previous implementation of the LPEX editor used to expand hard tabs
> according to the user settings - we ran into many usability problems,
> with users editing files created on other platforms and having the
> indentation messed by the various tab settings on each. Granted, a
> 'detab' command would be nice, to allow one to restore the file to the
> indentation settings on its originating platform ('detab' it's on the
> to-do list).
>
Actually, I'd prefer a more general 'format' command (with some
configuration settings), like in the JDT editor. If there isn't a
feature request written for that yet, let me know and I'll write one.
Randy
--
Randy Coulman
Senior Software Engineer
Key Technology, Inc.
RCoulman@keyww.com
|
|
|
| Re: LPEX indentation [message #17443 is a reply to message #17438] |
Mon, 11 February 2002 17:43 |
| Eclipse User |
|
|
|
Originally posted by: adrianstoristeanu.sympatico.ca
Randy,
>>> let me know and I'll write one.
If by this statement you mean you'll write the format code, by all means
please do!! :-) If you meant to write up the feature request, then it's
already on my to-do list...
>>> I don't think I agree with it
I am also aware of many not agreeing with the tabs issue (given that so
many other editors do it wrong :-), and their output must be somehow
supported), so it's also added to the list for a 'second look'.
Thanks a lot for your input!
Randy Coulman wrote:
>
> Thanks for the quick and thorough response. I don't think I agree with
> it, but I appreciate it.
>
> Most editors I've used have a setting that says 1 TAB = x spaces. Files
> with tabs show those embedded tabs as x spaces. To me, this makes
> sense. If I'm working with legacy code that uses 8-space tabs, then I
> will set my editor to use those settings. I'm not. I work with
> not-so-legacy code that was written with editors that have configurable
> tab widths.
>
> I've certainly heard the suggestion to not use tab characters before.
> My thought on the matter is that, if I've got all my tools configured to
> use the same tab width, then real tab characters are not an issue. This
> is the first programmer's editor I've come across that didn't allow me
> to configure things that way.
>
> >
> > A previous implementation of the LPEX editor used to expand hard tabs
> > according to the user settings - we ran into many usability problems,
> > with users editing files created on other platforms and having the
> > indentation messed by the various tab settings on each. Granted, a
> > 'detab' command would be nice, to allow one to restore the file to the
> > indentation settings on its originating platform ('detab' it's on the
> > to-do list).
> >
>
> Actually, I'd prefer a more general 'format' command (with some
> configuration settings), like in the JDT editor. If there isn't a
> feature request written for that yet, let me know and I'll write one.
>
> Randy
> --
> Randy Coulman
> Senior Software Engineer
> Key Technology, Inc.
> RCoulman@keyww.com
|
|
|
| Re: LPEX indentation [message #18693 is a reply to message #17443] |
Thu, 14 February 2002 08:51 |
| Eclipse User |
|
|
|
adrian wrote:
> I am also aware of many not agreeing with the tabs issue (given that so
> many other editors do it wrong :-), and their output must be somehow
> supported), so it's also added to the list for a 'second look'.
>
I agree it is a good idea to revisit this, for those reasons plus the fact
that some semantic dependencies have crept into Unix-origin utilities,
e.g. a line in a makefile that begins with a tab means something different
than a line that begins with 8 spaces.
It was fascinating too to see the rationale
> Tab
> characters, on the other hand, come from the UNIX world. Back then when
> preserving storage space was important, a tab character could be used
> instead of spaces. A tab character is expanded to 8 spaces. UNIX C
> compilers and UNIX editors expand a tab character to 8 spaces. Any
> legacy code that was written using tab characters was written with an
> editor that expanded the tab character to 8 spaces. If we interpret a
> tab character as anything other than 8 spaces, then the user will not
> see the legacy code as it was written.
which I have not seen before. The history isn't strictly accurate, it was
UNIX printer and terminal drivers that expanded tabs not the utilities, but
in any case that "legacy code" must be pretty ancient. Vi has been around
since the 70s, and has always had user-settable display tabstops.
Brian
|
|
| |
| Re: LPEX indentation [message #19311 is a reply to message #18693] |
Tue, 19 February 2002 10:56 |
| Eclipse User |
|
|
|
After a few lessons in Tab history (via an apparently-revisioninst detour), the
LPEX in the next CDT refresh will expand tabs on display according to the
tab-stop settings, rather than the currently hardcoded every-8-character
position.
|
|
|
Goto Forum:
Current Time: Sat May 03 13:54:14 EDT 2025
Powered by FUDForum. Page generated in 0.05578 seconds |
Home