What are the opinions. Do you like/dislike the new highlighting of case-labels?
e.g

   case a of
     *foo* :
     *bar*, *def*:
   end;

In your opinion, should it be:
- off by default
- italics
- underline
- other / color / frame?

Martin

-1 for underline

Mattias

off by default

thanks,
dmitry

off by default

-1 for italics. It isn't readable

Definitely not underline.
Maybe italics.

Regards
?ilvinas

Off by Default :-)

2010/5/24 Martin :

I like the "italics" of r25599.

+1 for italics by me :)

I vote for off by default.

Michael.

Le Lundi 24 Mai 2010 14:36:47, Martin a ?crit :

-1 for italic or underlined
no opinion for bold
+1 for different color

I like the one in r25603M

;)

IMO, case labels are constants, and should be highlighted as such.

Alexander Klenin wrote

IMO, case labels are constants, and should be highlighted as such.

+1 for handling just like any other constant value

Like string or like number or like identifier?

Mattias

- off by default
- other / color / frame?

Yes.

or, as I would say, yes, yes, and yes. ;)

Alexander Klenin schrieb: IMO, case labels are constants, and should be highlighted as such.

Yes, that sounds reasonable to me too.

Which one / What is highlighting same as constant?

const Foo = 1; // Foo is not highlighted:

literal constant:
'a' => blue by default
123 => dark(er) blue (navy) by default

Does this answer mean => case labels to be highlighted by color?

----------
Note that underline/italics can be applied in addition to existing highlight:

a blue string, a navy number, a normal-text identifer (e.g mrCancel) => all can be made italics

If you make them all colored, you override the original color.

Martin

Which one / What is highlighting same as constant? const Foo = 1; // Foo is not highlighted:

Then if Foo is a constand in a case statement it should be treated the same and not highlighted.

literal constant: 'a' => blue by default

If constants in the case statement are characters then they should also be blue by default.

123 => dark(er) blue (navy) by default

Yes, if the case constant is a number then it should also be in this color.

Does this answer mean => case labels to be highlighted by color?

I think they should be treated in the same as in a constant declaration.

This was already and always the case. any identifier, char, number is/was highlighted the same never mind if it is in a case label, an assignment, an expression .....

The question was, if a case label (any case-label, never mind it being a number, char, string, ident) should have any additional highlights. So case labels will stand out from other source?

The idea is that they are kind of a "section header" introducing a block of code, that is bound to a condition.

In other conditions, you have the "if then" being bold, and the actual expression local to the highlighted conditon marker (if then)

In case of a "case" the label can be far away from the highlight of the "case of" => it does not stand out, and can be overlooked.
- in small case blocks, it is easily seen by the indentation rules (if they are there, lets hope for it)
- in big case blocks, there may be many levels of indent outside, and inside the case. It is near impossible to tell if anything is exactly on the case-level of indent (especially if the case itself is scrolled of the visible screen).

Martin

Martin wrote

What is highlighting same as constant?

If the value is a character constant, highlight as a string constant. if the value is an integer, highlight it as a numeric constant. If the value is an enumeration value, highlight it as an identifier.

No need for extra italics, bold, etc.

-1 for italics
-1 for underline
+1 for Off By Default

+2 for off by default.

*case* something *of*
  MyCondition:
    DoSomething(myvar);
  AnotherCondition: *begin*
    DoThis(thisvar);
    DoThat(thatvar);
  *end*;
  default:
    Whatever();
*end*;

is clear enough (in lazarus) and makes sense as it is, imho.

- V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100524/4f198d12/attachment.html>

off by default -1 for italics. It isn't readable

dto.

DoDi

This was already and always the case. any identifier, char, number is/was highlighted the same never mind if it is in a case label, an assignment, an expression .....

Yes, and I think it should not be changed.

The question was, if a case label (any case-label, never mind it being a number, char, string, ident) should have any additional highlights. So case labels will stand out from other source?

I don't think so.

The idea is that they are kind of a "section header" introducing a block of code, that is bound to a condition.

Yes, but that's better done with indentation. I always use a formatting like this:

case x of
   1,2,3:
      begin
      ... do something
      end;
   4,5,6:
      begin
      ... do something
      end;
   7,8,9:
      begin
      ... do something
      end;
else
   ... do something
   end; // of case

In other conditions, you have the "if then" being bold, and the actual expression local to the highlighted conditon marker (if then) In case of a "case" the label can be far away from the highlight of the "case of" => it does not stand out, and can be overlooked.

Formatting helps here more I think. The same applies to "IF ... THEN ... ELSE". The ELSE part can be far away from the IF too.

I always follow a strict indentation rule (each block is indented by 3 characters, matching BEGINs and ENDs are either on the same line or are aligned in the same column, all commands of a block start on the same column as their enclosing BEGIN END, etc.). I don't see how this can be replaced by coloring. If you have nested case statements you will still not know to which of the case statements a constant belongs to unless you have a stict intendation rule.

[...] I always follow a strict indentation rule (each block is indented by 3 characters, matching BEGINs and ENDs are either on the same line or are aligned in the same column, all commands of a block start on the same column as their enclosing BEGIN END, etc.). I don't see how this can be replaced by coloring. If you have nested case statements you will still not know to which of the case statements a constant belongs to unless you have a stict intendation rule.

With strict indentation rules highlighting becomes less important.

But highlighting helps a lot reading code with unfamiliar indentation. The case label highlighting helps reading foreign code. Try it. For example for me the indentation of the MSEGui code is unfamiliar. The case labeling helps here.

IMO it is a useful feature. It just has not much gain for well (read: familiar) indented code.

The underline style is bad because it looks like a link. The italic style does not work with some carbon fonts. So italic should not be used there by default.

Mattias

Mattias Gaertner wrote

With strict indentation rules highlighting becomes less important.

Can anybody post a small screenshot of suggested highlighting? For those too afraid to use unstable trunk. Maybe even a temporary wiki page with various options?

Not seeing what you guys are talking about (because I'm not running latest trunk), I have to agree with Mattias. Well formatted code goes a long way in making it more readable even without syntax highlighting (or very limited syntax highlighting).

Try it. For example for me the indentation of the MSEGui code is unfamiliar. The case labeling helps here.

Poor Martin - he code always gets used as examples of hard-to-read code. :-)

Either way:

-1 for italics
-1 for underline

Graeme Geldenhuys wrote

Can anybody post a small screenshot of suggested highlighting?

Here is what it looks like with my color settings (bold highlight).

About the feature:

Personally I turned it off, since for me indentation makes case-labels readable enough.

But we could consider it to be ON by default not to go unnoticed by people who would like it. Those who don't like it can disable it forever in few clicks. Since it is already in trunk I guess most of us have already done so. But if it is disabled by default no one else could ever know about it.

One more suggestion is to add "case" block to example code box of the color settings dialog. This way one could instantly see the effect without going back
to source editor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: case_hilight.png
Type: image/png
Size: 7205 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100525/ee53ac21/attachment-0001.png>

That was my thought. Make people aware off it.

Sofar I counted 14 replies:
9 => off
2 => not specific off, but not liking the current italic 1 => on, color
1 => on italic

(not counting me)

So I switched it off in trunk again. probably lot's off people will never know it is even possible.

Done => only clicking on the label doesn't (yet) get you to the entry

A vote for bold, as it is both readable and these constants also introduce a block of code like "if...then", "for...do" or "while...do" which are reserved words -> have the same highlighting as default, so this would be consistent (yet preserving the string/number/identifier highlighting)

As I see, I'm the only one. No problem I think every opinion is important :P

"probably lot's off people will never know it is even possible." By the way actually I didn't know till this conversation but now for sure I'll turn it to bold :)

Kriszti?n

2010/5/25 Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100525/dc546316/attachment.html>

Mattias Gaertner wrote

But highlighting helps a lot reading code with unfamiliar indentation. The case label highlighting helps reading foreign code. Try it. For example for me the indentation of the MSEGui code is unfamiliar. The case labeling helps here.

this is one reason why i generally run all foreign-to-me code thru a "pretty printer" that formats the way i was taught to format pascal code... two spaces indention for each new section, not one or more than 2 and most definitely not tabs...

for example:

begin
   if foo then
     begin
       bar := foo;
       foo := not foo;
     end;
   if bar then
     begin
       foo := bar;
       bar := not bar;
     end;
end.

similar for var, const, and type declarations, too... always two spaces...

waldo kitty schrieb: two spaces indention for each new section, not one or more than 2 and most definitely not tabs...

I find 3 spaces much more readable.

But why have an indentation after BEGIN? There is no new block to start after BEGIN. I would indent like this:

begin
if foo then
   begin
   bar := foo;
   foo := not foo;
   end;
if bar then
   begin
   foo := bar;
   bar := not bar;
   end;
end.

You immediately see that there are two IF statements within the program block. If you indent after BEGIN too, then this is not so obvious (to me).

Ok, in the end it may be all a matter of what you are used to.

similar for var, const, and type declarations, too... always two spaces...

Agree.

--- El lun 24-may-10, Martin escribi?:

my vote:

+1 off by default
+1 italics

Jesus Reyes A.

From: J?rgen Hestermann [mailto:]
Sent: 26 May 2010 06:07

I've worked in a number of places which have different styles, my personal pref is with waldo kitty. Whilst I see where you are coming from in your indentation, if you indent as waldo suggests certain bugs or compilation issues can be more immediately apparent - do the begins & end match up? It's difficult to see when they are at the same level as the rest of the code.

Some places I've been like the begins to be inline with a conditional/loop declaration/etc, but I've never liked that. With one (large multinational) Their chosen style for if/elseif/else was: if x then begin
code
end else if y then begin
code
end else begin
code
end;
Which I found to be as helpful as a ice teapot, as scanning down you see one if with three ends and no context for what was happening in between..

Anyway, having seen the screenshot that Vladimir put up, I quite like it (not using a terribly uptodate version at the mo, whilst some pascal dev is on hiatus). I would opt for it being on (I know it's a quiet voice in a sea of no!), and bold wouldn't be a bad idea, or just another distinctive colour.

:shrug:

Duncan

Duncan Parsons wrote

Anyway, having seen the screenshot that Vladimir put up, I quite like it (not using a terribly uptodate version at the mo, whilst some pascal dev is on hiatus). I would opt for it being on (I know it's a quiet voice in a sea of no!), and bold wouldn't be a bad idea, or just another distinctive colour.

I changed it to off by default when I introduced the user-definable colorschemes.

But i am kind of glad that at least a few people share my opinion.

I guess a previous poster was right. Many people only read code they are familiar with, or that has easy to read case statements anyway. (after jedi-format).
On the other some of the case statements I had to look at (and no, I did not write them myself) are less easy to detect, even though they use proper indent.
But if:
- a single block in the case, spans over 50 or more lines (multiply screen pages)
- is already indented 4 or 5 levels at the start (so you can no longer tell how many levels that are by just looking at it, could be 8 space, could be 10)
- has several nested if, or other blocks within it.

[ don't start arguing, that then the code should be rewritten, => to rewrite the code one must read it first]

then indent alone is almost useless to make out where a case-block starts. All you have is a ":" at the end of the label. not that easy to spot. (and if it's an else, all you have is a simcolon on the end of the previous line, that's a guaranteed one to overlook)

Martin

This is my preferred style as well, with the least line count.

Which I found to be as helpful as a ice teapot, as scanning down you see one if with three ends and no context for what was happening in between..

It's equivalent to a case statement, where only one of multiple branches is taken at any time.

It also is compatible with languages that deserve no additional begin-end brackets (Modula...). I'm still waiting for an fpc front-end for that simplified syntax, which needs no further discussion about the placement of the added begins and ends, increases readability by their omission, reduces code size and speeds up compilation once more.

We'll never come to an agreement about *the* best representation, unless evitable begin-end pairs have been removed from the syntax.

The only other solution were a formatter that allows to flip between all the styles, and means to convert to some fixed (SVN) repository style before an commit or patch creation.

DoDi

thats one of the things i like about it.
having the *option* to make awfull code more readable is good (required in some cases) - but it shouldn't make proper code less readable.

yes, you must read the code to rewrite it - but if a programmer wrote code that way for me, id have them stay back after 5pm and have it written properly. (ok, not practical on open source!)

- V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100526/ef987f92/attachment.html>

if you indent as waldo suggests certain bugs or compilation issues can be more immediately apparent - do the begins & end match up? It's difficult to see when they are at the same level as the rest of the code.

If indentation is "overworked" it doesn't tell you very much anymore. If nearly each line is indented, then it becomes unclear and confusing to me. For very short code snippets it may work but if you have 10 or 20 levels of indentation (nested WITH, CASE, FOR, IF, ...) then adding an artificial indentation for each BEGIN/END pair would nearly double the number of indentations and would make it very complex IMO. Also, the indentation should be independend on whether only one command follows or multiple:

if a=b then
   do-something

and

if a=b then
   begin
   do-something
   do-something-else
   end;

should be indented identically to stay logical. Having it

if a=b then
   begin
      do-something
      do-something-else
   end;

would also clutter it too much IMO. The chance of consecutive lines starting in the same column is much less. And only they give a certain structure in the code. Also, whenever I have an indentation I know that this means that the linear code flow is interrupted by a loop or a branch.

Regarding missing BEGIN/ENDs: They may not stay out so much if they are aligned with the block but you can still check easily whether each block (of more than one command) starts with a BEGIN and ends with an END. Also, this is needed much less often than checking the code flow.

Yes, I would also not do it that way. Just imagine a missing BEGIN or END. Or adding another command in front of the second IF statement: You would have to enclose the new statement and the following IF with BEGIN/END. But where to place them? You can't see it immediately. But when having it formatted like this

if x then
   begin
   code
   end
else
   if y then
      begin
      code
      end
   else
      begin
      code
      end;

you can immediately see that the new-command has to be inserted like that:

if x then
   begin
   code
   end
else
   begin
   new-command
   if y then
      begin
      code
      end
   else
      begin
      code
      end;
   end;

Ooops. Something went wrong with the formatting here. What I meant was: --------------------
But when having it formatted like this

if x then
   begin
   code
   end
else
   if y then
      begin
      code
      end
   else
      begin
      code
      end;

you can immediately see that the new-command has to be inserted like that:

if x then
   begin
   code
   end
else
   begin
   new-command
   if y then
      begin
      code
      end
   else
      begin
      code
      end;
   end;
--------------------

IMO thats redundant lines + more scrolling to read the code. whereas:-

if x then begin
  code
end else begin
  if y then begin
    code
  end else begin
    code
  end;
end;

involves less scrolling when its big, or when using smaller screen. where the semicolons should go is clear
every line is functional, no redundant lines
more like one-line if

- V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100526/dbcc1f24/attachment.html>

    new-command;

dammit, missed new-command when reading your code :S

also kinda missed your point tbh...

if x then begin
  code
end else
  if y then begin
    code
  end else begin
    code
  end;

both methods are as easy as each other for where to place the begin/end/new-command, IMO.

- V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100526/51e64ee5/attachment.html>

I'm a fan of "half-indentation", showing clearly as well the alternatives, as the start and end of the block of choices, while saving lines.
With "else" I practically always do "end else begin" to make things more clear. (Code templates are nice :) )

if x then begin
  code
 end else begin
  if y then begin
    code
   end else begin
    code
  end;
end;

I seldom do:

if x then begin
  code
 end else if y then begin
  code
 end else if z then begin
  code
end;

IMHO this looks quite nice, but as technically the last end is not the match of the first end (as suggested by the indentation) I can't bring myself to like it.

Michael

I always put begin,else,end on newlines. If they were not important they would be omitted.

That is a strange argument... "important" => line of their own

Now before I take part in this hijacked thread (it was about highlighting, not indent). IMHO the exact style ot intend is mostly a matter of taste. Wahtever you grew up with (or are used too), seems most readable.
Besides this, there is pro and contra for all the styles, and no scientific correct choice.

But as for you saying, I couldn't resist a bit of a sarcastic answer.

To me each word (keyword, identifier, or else), each bracket, comma, *semicolon*, assignment or other operator => they are all important. Yet I don't put them all on individual lines....

Martin

J?rgen Hestermann wrote

But why have an indentation after BEGIN? There is no new block to start after BEGIN. I would indent like this:

so you can see the begin and end...

in any case, as i originally stated, it is how i was taught and also how all of the books i have on pascal indent, as well... the earliest of the pascal books in my library that i can currently lay a hand on is copyright 1986 so i can go at least that far back to provide examples... i have older books, too, but cannot lay my hands on them at the moment...

Who is to say that the begin is part of the block? (Anyone is free to tread it as such, but where is it officially defined?)

Looking at the way it is normally described in english (and being a bit picky):
I usually see statements like " A begin starts a new block" And not like "a begin started a new block"

Then again, if you apply the same analysis to "end", then "end" would need to still be indented, while "begin" wasn't....

Martin

J?rgen Hestermann wrote

But when having it formatted like this

if x then
   begin
     code;
   end
else
   if y then
      begin
        code;
      end
   else
      begin
        code;
      end;

you can immediately see that the new-command has to be inserted like that:

if x then
   begin
     code;
   end
else
   begin
     new-command;
     if y then
       begin
         code;
       end
     else
       begin
         code;
       end;
   end;

i also recall how i used to scroll thru hundreds of pages looking for a procedure that i needed to work on... using (holding down) the arrow keys to scroll hundreds and hundreds of lines, i wasn't looking for specific code, at that point, but more of the flow of the indents... in fact, one might say that i would "blur" my eyes so as to see the "shape" of the left side of the code... i definitely wasn't focusing on it or trying to read it at that point...

i'm not sure how to really explain it but maybe similar to looking for a section of shoreline by picking out the surrounding areas...

indents are nothing... they are simply spaces and can actually be eliminated from all source code... the compiler doesn't care about them... they are a human necessity (crutch?) ;)

the above format hurts my eyes... i cannot see else, for one thing, and cannot separate out the individual code blocks... it is really bad when it spans 50 lines or more... especially when it covers several pages... at that point, you loose the rest of it...

involves less scrolling when its big, or when using smaller screen.

what's wrong with scrolling? here's another thought... what happens when you print out the code and then draw in vertical lines to delineate the individual blocks? i've had to do that many many times to locate where a semicolon or end statement was left out... it really sucked wasting sometimes hundreds of sheets of continuous feed paper so that it was all connected together... i wouldn't try it today with the single sheet feed stuff... this is one reason why i (still) keep several continuous feed printers around ;)

where the semicolons should go is clear every line is functional, no redundant lines more like one-line if

hehehe... more like a one line program :P ;)

IMHO the exact style ot intend is mostly a matter of taste. Wahtever you grew up with (or are used too), seems most readable.

+1

procedure quicksort;
   procedure sort(l,r: index);
      var i,j: index; x,w: item;
   begin i := l; j := r;
      x := a[(l+r) div 2];
      repeat
         while a[1].key < x.key do i := i+1;
         while x.key < a[j].key do j := j-1;
         if i <= j then
         begin w := a[i]; a[i] := a[j]; a[j] := w;
            i := i+1; j := j-1
         end;
      until i > j;
      if l < j then sort(l,j);
      if i < r then sort(i,r)
   end;
   begin sort(1,n)
end;

Dr. Dr. h. c. Niklaus Wirth
Algorithmen und Datenstrukturen
2. Edition
Stuttgart 1979
page 117

R.

Marco van de Voort wrote

I always put begin,else,end on newlines. If they were not important they would be omitted.

exactly :)

im looking for indents, your looking for begin/ends. i think this is where 'what your used to' comes in.. we both use what suits us. when 'code' makes the 'if' big, then i put the 'code's into their own procedures/functions. keeps things neat & orderly. imho what the 'if' is doing is seperate from what the 'code' is doing.

taking the AI perpective:-
'if' - making decision.
'code' - acting on decision.

this lets you debug/maintain the decisions making from the acting on decisions easily, and lets others pick up whats going on quickly..

i find scrolling up & down constantly to make sure what i've done isn't going to adversely affect the other code (proof-read the code) is an unnecessary inconvenience.

i'll refer to my point below re semicolons :)
where end's should go is clear as well - at the beginning of every indented line, unless starting a new if.

i can only aspire to such things 8D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100527/a7153b06/attachment-0001.html>

is something missing? what are the "index" and "item" types?

Hello Lazarus-List,

wk> the above format hurts my eyes... i cannot see else, for one thing, and cannot wk> separate out the individual code blocks... it is really bad when it spans 50 wk> lines or more... especially when it covers several pages... at that point, you wk> loose the rest of it...

That's because your search patterns are tied to your coding style. I'm unable to follow your (and others) style because to me "begin" is sintax sugar ( that's a personal appreciation, plese drop the guns :) ). I instantly catch the else because there is an "end" with something after.

I'm not saying that my style is better, and nobody should try to convince others which is the best one, at most "In this project the style is this dot!"

I'm using this style since a lot of time because is the only one that I can hold across multiple programming languages with minimal changes. I'm sure there are more, but that's mine, not better, not worst. ( C coders say the same about my style :-) ).

This is why I somethings think C (mostly unix projects) or Java have some reason behind there madness. They often use Tab character for indentation and set it equal to 8 spaces. 8 is a bit much I think, but it is much easier to see indentation that 2 spaces. Maybe 4 spaces is a good middle ground.

If only Elastic Tabstops was implemented in Lazarus IDE, then everybody (I say that with a pinch of salt) should be happy as you can easily configure your own personal indentation widths, and will *not* affect other's indentation preferences. Elastic Tabstops always uses the least amount of tabs - normally one or two only, but widths of tabs are automatically calculated per code block.

In the mean time, I have already considered switch all my pascal code to using Tab characters. That way each developer can specify what indentation width they want, but this is rather difficult to do in Lazarus. Why? Because tab width (editor preference) is a global option, not per project, so it will affect all other projects too, which is not ideal. And standard usage of Tab characters are not really as good as Elastic Tabstops.

nickgravgaard.com/elastictabstops/
There is a Java applet you can play with and see how indentation works. But read the theory first to understand what it does. It's pretty clever!

PS:
I have tried once to implement Elastic Tabstops in Lazarus IDE, but SynEdit was just too confusing for me. And this was before Martin's major SynEdit refactoring and IFDEF code cleanup. Maybe SynEdit is easier to use now - I don't know.

That is why I love half-indentation:
. + two spaces after a "begin", unless the line begins with an "end" . - two spaces before a line that is just "end;"
. - one space for the line "end else begin"
. + one space after that line

This clearly shows the "if" (or "while" or whatever) block structure, as the "if" (or whatever keyword) that starts the line that ends with a "begin" is at the same column as the final corresponding "end". Moreover the "else" can easily be found as it is "half unindented" regarding the "if" block.

The downside is that more indentation space is necessary versus indenting just a single space. But for readability, too deep structures should be avoided (by calling a procedure) anyway.

-Michael

In C this notation really look ridiculous: just a single {
in a line.

Funny: I do use a single "end;" (or "};" in C. (in fact always with a ";" even if this might not be totally "state of the art"). Perhaps it would be even better to define the begin to be "outside" of the block and the end to be "inside":

code 11
if x then begin
  code21;
  code22; end;
code 12;

looks really nice and consistently done to me right now, but I don't remember to have ever seen this anywhere.

-Michael

Beware Graeme. Seeing reason behind madness might lead to madness ;)

Tabwidths is more like line endings and encodings. It should be per file.

nickgravgaard.com/elastictabstops/ There is a Java applet you can play with and see how indentation works. But read the theory first to understand what it does. It's pretty clever!

I agree, it's better than fixed tabs.

It should be doable.

Mattias

Mattias Gaertner wrote

Beware Graeme. Seeing reason behind madness might lead to madness ;)

:-)

Tabwidths is more like line endings and encodings. It should be per file.

Maybe Lazarus can one day support editor style hints inside comments. Some editors support this already like: vi, vim, jEdit etc.. The first comment inside each source file defines the indentation style used. The editor then adjust for that style for that file only.

I agree, it's better than fixed tabs.

A nice bonus with Elastic Tabstops is that you can uses proportional fonts too (often prettier than mono fonts) - yet indentation is still perfectly aligned.

It should be doable.

Um, I should maybe give this another try and some point.

im looking for indents, your looking for begin/ends. i think this is where 'what your used to' comes in..

It's not only use, it depends on how individual people perceive the world. There are people that prefer dark text on a light background, others hate that. We must understand that people *are* different, and so have different *needs*.

DoDi

Tabwidths is more like line endings and encodings. It should be per file.

It should be per user, regardless of files. But that may result in conflicts with SVN, even if only tabs are used to indicate indentation levels.

BTW when I wrote my C decompiler, the final formatting of the source code required about the same amount of code than the transformation of ASM into C - and this was the implementation of only one (my) style.

DoDi

For me it's not a matter of definition but of logic. A "block" is a sequence of commands that are executed step by step one after the other. I always align these commands on the same column. A conditional branch or a loop breaks this linear execution so another level of indentation is added. And because a single command is the same kind of block as multiple commands (enclosed with BEGIN/END) it's logical to align them all at the same column. I then see immidiately when a block (of more than 1 command) does not start with a BEGIN or does not end with an END. Having this logic is very important to me so that I can see the order of execution. When having a branch like this

if xxx then
   begin
   ...........
   end
else
   begin
   ...........
   end;

and the number of commands between BEGIN/END is large then I only have to scroll down (with the cursor at the BEGIN) to find the matching END. Same with a loop:

for xxx do
   begin
   .........
   end;

Everything between BEGIN and END is part of the block which is executed by the FOR loop. And the same for REPEAT:

repeat
.....
.....
until

It's the same logic, although no BEGIN/END pair is needed. If I would indent one level more with each BEGIN/END then the indentation would be different with or without these indentifiers. When the block consists of only one command or when I have a REPEAT loop then the indentation would be less. To me that's illogical and inconsistend and harder to read.

But, it seems that everybody has got used to his own style so it's unlikely that someone would change their style.

And that is one of the things Elastic Tabstops will resolve (prevent). Yet each developer will have there preferred indentation amount.

And what you mentioned is a perfect example why fixed width tabs (static tabstops) fail miserably - because the amount of Tab characters used will vary based on user preference. It elastic tabstops they will not.

J?rgen Hestermann wrote

A "block" is a sequence of commands that are executed step by step one after the other.

"begin" and "end" are not executed, but just limitations of the block they mark, so it's a matter of taste if they are felt to be inside or outside of the block or if they even get a special handling

inside;
if x then
  begin
  incode;
  end;
outcode;

outside:

if x then
begin
  incode;
end;
outcode;

special handling 1:

if x then begin
  incode;
end;
outcode;

special handling 2:

if x then begin
  incode; end;
outcode;

-Michael

(just a note)

In the early days of lazarus I learned not to trust indents. When you have code committed by different ppl, using tab, 1sp 2sp or 3sp as indent, you cannot say for sure if an indent is part of the if statement or a misindeted following statement. Unless you read the whole if statement first.
This is why I personally really hate the above code.

Marc

i don't know if i can retrain my thumb to hit the TAB instead of the space bar as it has been trained to do these past 30+ years i've been coding :? :P

i don't see begin/end as inside or outside... they _are_ the boundary or frame of the block ;)

waldo kitty wrote

i don't know if i can retrain my thumb to hit the TAB instead of the space bar as it has been trained to do these past 30+ years i've been coding :? :P

:-)
The sad thing is, the Tab key was invented for indentation and alignment, yet Pascal and many other languages refrain from using that key. I really think it's the limitations of the editors that forced us to start using the spaces bar to align and indent. Word Processors have variable width tabstops, elastic tabstops do the same as word processors but tuned for programming - it just makes more logical sense to use the tab character correctly. And obviously Programming Editors need to get with the times. Limited to mono fonts and fixed width tabs are getting rather old - imagine MS Word or OpenOffice Writer still had those limitations. :-/

I doubt that elastic tabstops really can do that. It must be context sensitive, what introduces dependencies and chances for misbehaviour.

DoDi

Well, that is exactly what Elastic Tabstops (ET) can do. If you read the information on the ET home pages and understand how it works, you will clearly see what I mean. Each user can set there preferred indentation (as pixels - not characters). ET then translates each Tab character so the desired indentation based on code around each line. It adapts indentation (via display only) without the need of adding extra Tab characters in the code.

I use the tab key for indentation, never alignment (after text). This way it always looks good for everyone's tab-space settings. In the very rare case I need alignment, I'll use spaces. You are writing code, after all, not designing a powerpoint presentation.

Henry

Just try the ET java demo. One tab character can do indentation and one tab character can do alignment (eg: comments after code). No matter the developers indent/alignment preference, everybody's code will look they way they like it.

Another awesome thing which your method of alignment fails miserably (using spaces). If the code text becomes longer, you need to re-align all the other comments. ET does this all automatically (without the need for extra tab characters) - just keep coding. This is all visible in the small java ET demo (but remember the small java demo is not tuned for performance with large files - the gEdit plugin is much faster).

This is why I don't put blocks of comments after code. Imho multi-line comments belong on their own lines, otherwise it messes up the way I read code. You're also more likely to exceed 80 chars width if you do this. Personal preference, of course The elastic tab stops are clever, but you are limiting yourself to editors that support them.

Henry

Henry Vermaak wrote

This is why I don't put blocks of comments after code. ?Imho multi-line comments belong on their own lines, otherwise it messes up the way I read code. ?You're also more likely to exceed 80 chars width

A very common case where comments are used after code is in file structures and header translation.

Where is a simple example, and I have lots more like it. For my normal (hand-written from the start) code I normally don't do this style of formatting though.

------------------------------
  TExtendedHelpFileHeader = packed record
    NumFontEntry: uint16;             // FONT TABLE:   Number entries
    FontTableOffset: uint32;          // FONT TABLE:   Offset in file
    NumDataBase: uint16;              // DATA BASE:    Number of files
    DataBaseOffset: uint32;           // DATA BASE:    Offset in file
    DataBaseSize: uint32;             // DATA BASE:    Size in bytes
    EntryInGNameTable: uint16;        // GLOBAL NAMES: Number entries
    HelpPanelGNameTblOffset: uint32;  // GLOBAL NAMES: Offset in file
    StringsOffset: uint32;            // STRINGS : Offset in file
    StringsSize: uint16;              // STRINGS : Total bytes of all strings
    ChildPagesOffset: uint32;         // CHILDPAGES : Offset in file
    ChildPagesSize: uint32;           // CHILDPAGES : Total bytes of all strings
    NumGIndexEntry: uint32;           // Total number of Global Index items
    CtrlOffset: uint32;               // CTRL BUTTONS : offset in file
    CtrlSize: uint32;                 // CTRL BUTTONS : size in bytes
    Reserved: array[0..3] of uint32;  // For future use. Set to zero
  end;
  TPExtendedHelpFileHeader = ^TExtendedHelpFileHeader;
------------------------------

if you do this. ?Personal preference, of course ?The elastic tab stops are clever, but you are limiting yourself to editors that support them.

A rather weak statement I think. 99.9% of developers probably use 1 editor (ide) for a specific language. How often do developers developing LCL based applications switch to another editor (instead of Lazarus IDE)? Probably never. For that other 0.1% they probably only use 2 editors max. For those editors that don't support ET, there indentation should look fine, but trailing comments (alignment) might not. Code should still be very readable though.

Wtf? It's hundred percent true. Is that your definition of "weak"? If your editor doesn't support elastic tabstops, and you rely on elastic tabstops for alignment, the code won't line up properly. That's a fact.

I don't use lazarus when I'm hacking something via ssh, I use vi.

Henry

Henry Vermaak wrote

Wtf? ?It's hundred percent true. ?Is that your definition of "weak"? If your editor doesn't support elastic tabstops, and you rely on elastic tabstops for alignment, the code won't line up properly.

What I am saying is that Tab characters are supported in ALL editors, so indentation using tab characters is not a problem. ET uses the Tab character too. Also ALL editor support a user define tab width for the tab character. So again, switching between ET enabled or not editors, your CODE will still be readable if you adjust the tab width to what you are used too in each editor (hardly any effort to do).

The *only* thing that _might_ not look correct is alignment of comments behind your code - and like you said, neither you or I normally (and probably many others too) use such multi-line commenting styles.

Take the trouble and load gEdit with the ET plugin. Format some pascal code, then view it in Lazarus IDE. It's not really as bad as one would expect.

A very common case where comments are used after code is in file structures and header translation.

Which can hardly be automized for any real class, having methods with argument lists, properties etc.

I don't want to change my coding style for the sake of using a "clever" tool, that may fail with every other source file. Picking only nice results doesn't help with all the ugly cases.

Automatic indentation is okay, because it's reversible. But tables with columns are something for text processing systems with a specialized layout mechanism, not for simple source editors and shared source code. I'd rather prefer to hide comments and begin/end pairs on demand, in addition to foldable blocks, so that I can see only the essential source code when required.

DoDi

Hans-Peter Diettrich wrote

Which can hardly be automized for any real class, having methods with argument lists, properties etc.

On the contrary, it can - and will be very easy. Simply insert a single Tab character where you want things aligned. The ET enabled editor will do the rest when you open the file for editing.

Automatic indentation is okay, because it's reversible. But tables with columns are something for text processing systems with a specialized layout

Again, here is some of my other formatting style I use in my code.

1) Aligning the identifier in a class, irrespective if it is a function, procedure, constructor etc.
See untitled1.png.
2) Align the assignment characters so it forms a visual block. See untitled2.png
3) Not something I do often, but see it often in other developers code. Align the types
in a var declaration. See untitled3.png
4) If parameter lists are long or many, and align them to easier see the different ones and
what types they are. See untitled4.png

I can list many more examples, where ET can be very useful. All alignment is done simply by pressing the Tab key once, ET does the rest. All these are just with my coding style, so I can just imagine other developers might even have there own examples.

Anyway, I'll try and implement ET in SynEdit at some point - seeing that the SynEdit code has had some nice code clean-up recently. Obviously everything added in Lazarus IDE is toggled via a environment option, because you can never please everybody.

hey! have you been reading my code? :P i've been known to do all of those depending on my mood :lol:

i wanted to toss one more thing into the fray... i use spaces because they are always the same size no matter what editor or viewer i use... i truly hate when i have to paste something that's tab spaced and the tabs end up "broken"... an example is pasting code/text into web forums wrapped with their "code tags" to preserve the formatting... the tabs become spaces in the browser and the alignment is thrown off... it doesn't matter if it is a table, chart or simply source code...

another example is what i commonly see when i edit (in this case) perl files... on the one *nix that i do a lot of perl coding (it is the entire GUI), i generally use the editor in mc because it is there and i'm familiar with it... however, when i'm logged in via ssh, being able to do a copy or paste to/from the workstation's local clipboard to/from the ssh session is neigh impossible in that editor (at least, i haven't figured out how if it is possible)... so i follow the KISS principle and do it like this...

1. save the current file
2. exit the editor
3. fire up vi
4. do the copy or paste
5. save and exit
6. return to the preferred editor

even looking at the same text between those two editors hilites the differences with tabs... so i use spaces... they are universal and everything is aligned exactly as desired no matter what editor or viewer is used...

i still can't get my thumb to hit the tab key, either... it is much too connected to the space bar... it also has this perfect double twitch that spaces things over just perfectly ;)

waldo kitty wrote

their "code tags" to preserve the formatting... the tabs become spaces in the browser and the alignment is thrown off... it doesn't matter if it is a table, chart or simply source code...

Maybe Lazarus IDE needs a special copy command that automatically converts Tabs to Spaces - solely for the purpose of pasting into forums or email. :-)

with it... however, when i'm logged in via ssh, being able to do a copy or paste to/from the workstation's local clipboard to/from the ssh session is

Pasting to a ssh session where mc's editor is running is easy. Select the code in your local system and copy to clipboard. In the Terminal window running your SSH session, don't use keyboard shortcuts, you the Edit > Paste menu command of the terminal itself. This works for me.

i still can't get my thumb to hit the tab key,

Well, I would seriously go see a doctor if youth thumbs can actually reach the Tab key while doing touch typing. Super dexterous. ;-)

hehehe... nice! :) :P

nononono... don't need that, really :laugh:

ahhh... i don't think i've dug thru that menu in putty... i'll have to take a look and see what i can find... i've been used to just drag to hilite and the text is in the clipboard... or just right click and the clipboard contents are pasted where the cursor is... i think one of my problems, without trying it to be clear, is that mc is mousable or at least when i try to drag or paste, the clicks are interpreted by mc as screen movement stuffs... IDK... we'll give it a try and see what i can find ;)

> i still can't get my thumb to hit the tab key, Well, I would seriously go see a doctor if youth thumbs can actually reach the Tab key while doing touch typing. Super dexterous. ;-)

yeah, no doubt! :lol:

waldo kitty wrote

i don't see begin/end as inside or outside... they _are_ the boundary or frame of the block ;)

To represent this as an indentation you would need to go_

if x then
  begin
    incode;
  end;
outcode;

I never saw anything like that (and don't like it).

-Michael

That's how I indent. Even the two spaces are correct.

Much of the FPC project is in that style too.

that is basically exactly how i code and have always done so... i made a decision a looooooooong time ago to avoid the possibility of "ambiguous" coding such that i do not take shortcuts (for the most part) and possibly end up with something that doesn't work as intended... the handing "else" comes to mind (even though i had never heard it specified like that before)...

granted, in cases of one liners depicted above, i may or may not do the begin/end "wrapping"... it all depends on the situation and, as written by myself before, my mood... this is true for not just "if" statements but all other "decision tree" types...