[fpc-other] Underscores in numerical literals - grouping

[Graeme Geldenhuys]

[moved to fpc-other, from fpc-users mailing list]

hahaha... I love how a con is “fundamentally different concept”.
How is that a con?

Fundamentally different to the way current IDEs/editors process their
text -> too much work for a feature no one gives a flying f**k
about. Got it?

Yet probably the two most popular IDE's in the world (Eclipse and MS
Visual Studio) both support Elastic Tabstop. :-/ And that's just two
IDE's I know of. Some text editors (stand-alone or built into an IDE)
have more advanced functionality than most people realise (or more
features than what Lazarus's TSynEdit supports), but never realised the
potential of taking advantage of those features - or thinking outside
the box.

Think about Syntax Highlighting. For decades everybody coded in plain
2-tone text, and everybody accepted it as the norm. Then somebody
thought outside the box and implemented syntax highlighting to make it
easier on the developer. Yet, Syntax Highlighting doesn't add any extra
functionality to your code or the compiler - but does require a
"fundamentally different concept and implementation". Now every text
editor on the planet supports syntax highlighting and accepts that as
the norm.

The Elastic Tabstops implementation is actually pretty simple - way
under a 100 lines of code. All that ET needs from a text editor is that
they support multiple tabstop per line and where each tabstop can have a
different width. Optionally (but preferred), also where tabstops are
defined in pixels not x number of spaces (but this is not a requirement).

ps:
Apparently, according to Martin Friebe, implementing ET support in
Lazarus is really simple. Bar the fact that it will use x number of
spaces as indentation, not pixels. But I don't know enough of
Lazarus's source editor and TSynEdit integration to know where to
implement a TSynEdit line filter.

Regards,
Graeme

[Graeme Geldenhuys]

[reply moved to fpc-other]

My conclusion: That tabs costs less cpu time in Pascal code is a myth.

Bottom line, in both your 2nd and 3rd set of attempts, at least 2 out of
the 3 compiles were faster than the (1st) baseline times. So my
statement about it will take less time because there are less bytes to
process holds true. :-) I never said by how much faster though. ;-)

To get more accurate results one would have to reduce the test to only
parsing source code, and exclude things like deleting PPU files,
compiling and binary linking. An exercise for a rainy Sunday afternoon. :)

I was impressed by how much disk space the source code reduced by.
That's 3.7MB [minimum] less bytes to parse and scan.

Regards,
Graeme

[Mattias Gaertner]

On Tue, 22 Nov 2016 14:47:10 +0000

Post by Graeme Geldenhuys
[reply moved to fpc-other]

My conclusion: That tabs costs less cpu time in Pascal code is a myth.

Bottom line, in both your 2nd and 3rd set of attempts, at least 2 out of
the 3 compiles were faster than the (1st) baseline times. So my
statement about it will take less time because there are less bytes to
process holds true. :-) I never said by how much faster though. ;-)

Invalid cherry picking. Is the smiley for that?

Post by Graeme Geldenhuys
To get more accurate results one would have to reduce the test to only
parsing source code, and exclude things like deleting PPU files,
compiling and binary linking. An exercise for a rainy Sunday afternoon. :)

Deleting PPU files takes 0.7 secs.
Why should compiling and linking be removed from the compiler time?

Post by Graeme Geldenhuys
I was impressed by how much disk space the source code reduced by.
That's 3.7MB [minimum] less bytes to parse and scan.

The 3.7MB is 0,5% to 1% depending on source distribution.

Graeme, the space and time savings are simply weak arguments for using
tabs in Pascal. You gave some better arguments for Elastic tab stops
and you should concentrate on them.

Mattias
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Mattias Gaertner
Why should compiling and linking be removed from the compiler time?

Compiling works on in-memory data structures (supplied by the tokenizer
and such) and linking works on newly created object files on disk. Both
have nothing to do any more with the original source code units.

Regards,
Graeme

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Jürgen Hestermann]

I just tried elastic tab stops with JEdit a bit but they are too restrictive for me:

1.) They do not allow me to start a new table without having an empty line between.
The following indentation seems to be impossible with elastic tabstops (at least I did not found out how to do this):
aaaa bbbb cccc
dddd eeee ffff
gggg hhhh iiii
11 22 33
44 55 66
77 88 99
There is no way to specify when a block starts and ends other than empty lines.

Even worse, when having a block like above and I then start a new line which
has nothing to do with the above block this whole new line is taken as the first column
shifting everything above to the right (which is not what I intended).
Elastic tabstops are way "too smart".
They disturb more often than they help.

2.) When spaces are used instead of tabs (like in Lazarus IDE) then
my file has the same look on all editors with monospaced fonts.
When I would have used (elastic) tabstops then this would look
totally confusing in these editors.

3.) Together with the issues above the advantages are too few to let me put any time into this
(I already wasted too much time on testing and writing these emails ;-) )

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Jürgen Hestermann
1.) They do not allow me to start a new table without having an empty line between.
aaaa bbbb cccc
dddd eeee ffff
gggg hhhh iiii
11 22 33
44 55 66
77 88 99

I'm not sure I understand what exactly you are trying to accomplish. Do
you mean column data (think TAB delimiter data files like what Excel
exports)? See attached screenshot. Simply insert a TAB character between
every column of text.

Post by Jürgen Hestermann
2.) When spaces are used instead of tabs (like in Lazarus IDE) then

If you are going to use ET for your programming, you would convert all
your source code to TAB indented files. Some text editors (VIM, jEdit
etc) allow you to place a comment line within the first 5 or so lines of
text (they have a special name for it, but I can't remember it now).
Those are special editor instructions like defining TAB width, coding
style etc. If Lazarus IDE ever supported ET, that would be a useful
feature to add too. So Lazarus IDE could automatically use ET for your
code, but standard 2-space indentation for Lazarus LCL code.

I had a quick look in jEdit help under "Buffer-Local Properties".
From the documentation:

"
When jEdit loads a file, it checks the first and last 10 lines for
colon-enclosed name/value pairs. For example, placing the following in a
buffer changes the indent width to 4 characters, enables soft tabs, and
activates the Perl edit mode:

:indentSize=4:noTabs=true:mode=perl:
"


Regards,
Graeme

[Jürgen Hestermann]

Post by Graeme Geldenhuys

Post by Jürgen Hestermann
1.) They do not allow me to start a new table without having an empty line between.
aaaa bbbb cccc
dddd eeee ffff
gggg hhhh iiii
11 22 33
44 55 66
77 88 99

I'm not sure I understand what exactly you are trying to accomplish. Do
you mean column data (think TAB delimiter data files like what Excel
exports)? See attached screenshot. Simply insert a TAB character between
every column of text.

I just want it in the way I have shown in my email (via spaces).
The first 3 lines and the last 3 lines should *not* share the same tab positions!
Only each block of 3 lines should do so.
In your screenshot "11 22 33" is aligned with 'ggg hhhh iiii' which I do not want.
There should be 2 blocks each with their own columns.

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Jürgen Hestermann
In your screenshot "11 22 33" is aligned with 'ggg hhhh iiii' which I do not want.

Ah, okay. In that case you can't do it with ET, as they are consider
part of the same text block (think of a paragraph of text in a word
document).

Inserting a blank line between the two blocks will treat them
differently with different indentation widths. If your file format
supports comments, inserting a comment line between the two blocks will
also work.

Regards,
Graeme

[Jürgen Hestermann]

Inserting a blank line between the two blocks will treat themt
differently with different indentation widths.

Yes. But sometimes I do not want to be forced to
insert a blank line just to achieve this and
sometimes I even want to align what is separated
by a blank line.

If your file format supports comments,
inserting a comment line between the two blocks will
also work.

I tried a new file in JEdit (I don't know what format this has then)
but a line beginning with double backslash did not separate the blocks.
Even worse, it was taken as the first column of the whole block.

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Jürgen Hestermann]

Post by Jürgen Hestermann

Inserting a blank line between the two blocks will treat themt
differently with different indentation widths.

Yes. But sometimes I do not want to be forced to
insert a blank line just to achieve this and
sometimes I even want to align what is separated
by a blank line.

I am wondering how you can achieve this kind of
code alignment

---------------------
MyvariableA := 0;
Myx := 1;
MyProcedureCall(Param1,Param2,Param3);
---------------------

by using elastic tabstops and without having
an empty line between the 2nd and 3rd code line.
Wouldn't the 3rd line always expand the first
column of the block shifting the ':=' far to the right?
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

I am wondering how you can achieve this kind of code alignment

Yes, easily, because only lines 1 & 2 have TAB characters. Line 3 has no
TAB characters, so ET's algorithm doesn't need to do anything with it.
See attached screenshot.

Also remember, Object Pascal is not sensitive to whitespace (like some
other languages), so if need be, add blacks lines if you must. Often it
makes a method implementation easier to read too - separating related
tasks in a single method implementation. I do that, even when I don't
use ET. Also, if you want what things to be aligned when using an ET
enabled editor, then use spaces instead of a TAB character. Like any
programming style - make it work for you.

Elastic Tabstops will obviously not be a perfect fit for everybody -
nothing ever is. But (to me at least) it is a damn sight better than
anything before it. The pros far outweigh the cons for me. The pure joy
of multiple developers looking at the exact same file, but each
developer having their own style (indentation and padding) preferences
applied is a huge plus for me. Also in DDL SQL having field comments
perfectly align next to table fields is awesome. Also viewing TAB
delimited data dumps is awesome - giving text editors the ability to
view data like Excel or LibreOffice Calc.

Regards,
Graeme

[Graeme Geldenhuys]

Damn spelling mistakes. Seems I'm having finger troubles today. :-)

Post by Graeme Geldenhuys
other languages), so if need be, add blacks lines if you must. Often it

Should have been:

... so if need be, add _blank_ lines if you must.

Post by Graeme Geldenhuys
use ET. Also, if you want what things to be aligned when using an ET

Should have been:

... if you _don't_ want things to be aligned...



Regards,
Graeme

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Jürgen Hestermann
I tried a new file in JEdit (I don't know what format this has then)
but a line beginning with double backslash did not separate the blocks.
Even worse, it was taken as the first column of the whole block.

See attached.


Regards,
Graeme

[Jürgen Hestermann]

Post by Graeme Geldenhuys

Post by Jürgen Hestermann
I tried a new file in JEdit (I don't know what format this has then)
but a line beginning with double backslash did not separate the blocks.
Even worse, it was taken as the first column of the whole block.

See attached.

In your screenshot you use empty lines
but no comment lines to separate the blocks.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Jürgen Hestermann
In your screenshot you use empty lines
but no comment lines to separate the blocks.

It makes no difference... it has the same result. See attached
screenshot, where I added comments using a // prefix.


You seem to be missing how indentation or alignment is triggered with
ET. It only happens when a TAB (U+0009) character is found.


Regards,
Graeme

[Jürgen Hestermann]

Post by Graeme Geldenhuys

Post by Jürgen Hestermann
In your screenshot you use empty lines
but no comment lines to separate the blocks.

It makes no difference... it has the same result. See attached
screenshot, where I added comments using a // prefix.
You seem to be missing how indentation or alignment is triggered with
ET. It only happens when a TAB (U+0009) character is found.

Yes, I see now.
It will only be a problem when 2 (different) blocks
with elastic tabstops are directly following each other
(without a line that has no tabstops as a separator).

But this happens quite often in my code in function/procedure
declarations as I align the parameters and directly after this
the var declarations are aligned too (but not aligned to the parameter declaration):

----------------------------------------------------------------------
function MyProcedureThatDoesSomething(const Path,
SourceItemName,
TargetPath,
TargetItemName : MyStringType;
CopyProgressRoutine : CopyProgressRoutineTyp;
const Flag : boolean;
out ErrorCode : DWord;
var ItemSkipped : boolean;
const ExistingMode : OverwriteExistingModeTyp) : boolean;
var Flags,
VolumeS,
VolumeT : DWord;
S,T : MyStringType;
FileEntryS,
FileEntryT : BasicFileTyp;
H : hwnd;
----------------------------------------------------------------------

In this case I would need to insert an empty (or comment line) between
both blocks which I do not want in all cases.

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Graeme Geldenhuys]

Post by Jürgen Hestermann
But this happens quite often in my code in function/procedure
declarations as I align the parameters and directly after this

See attached screenshot. It shows three options.

1) your original code
2) I live to define each parameter individually with modifier
and data type. But this layout makes the code stretch for
to the right, meaning I might have to scroll horizontally
to see all the parameter definitions.
3) Slightly reworked (2) - no more horizontal scrolling required


I know coding style is a very personal thing. So I'm not saying you must
change your, I'm just showing examples of others.


Regards,
Graeme

[Graeme Geldenhuys]

Also, you didn't align the parameters in your screenshot as I did in my example.

If you want columns, then columns you shall have. ;-)
See attachment. I've also reduced the tabSize to 2, to make it more
representative of common Object Pascal coding style standards.

The only thing I can see that is still different to your original code
[which ET can't do] is make your const/var column right aligned.

See attached screenshot. Again, I've enabled jEdit's setting to show
where I inserted TAB characters to make it easier to reproduce.

In the end, you arrange your alignment according to the limitations
of elastic tabstops (ET)

Not at all. To the contrary, the "my style #2" is exactly the coding
standard I use in all my code (ET enabled or not). You are welcome to
verify this by looking at the fpGUI or tiOPF code available on
SourceForge. I use a coding style that is very similar, if not exactly
like, the code shown in Delphi 7's VCL units. So no, I didn't adjust my
styling to fit ET in any way, it just happens to work very well together.


ps:
In case you are interested. jEdit supports local buffer settings
embedded inside the file you are editing. For Object Pascal code,
you can place the following anywhere in the first 10 or last 10 lines
of a .pas file. If I had to use it, I would personally stick it at
the end of the unit, far out of the way.

{ :mode=pascal:tabSize=2:elasticTabstops=true: }


Regards,
Graeme

[Jürgen Hestermann]

Post by Graeme Geldenhuys
If you want columns, then columns you shall have. ;-)
See attachment. I've also reduced the tabSize to 2, to make it more
representative of common Object Pascal coding style standards.

Well, actually I would like to have the tabsize zero.
I just want to align with tabs, not add space.
These 2 things should not be combined.

Post by Graeme Geldenhuys
The only thing I can see that is still different to your original code
[which ET can't do] is make your const/var column right aligned.

Yes, although this would be no show stopper for me.

Post by Graeme Geldenhuys
See attached screenshot. Again, I've enabled jEdit's setting to show
where I inserted TAB characters to make it easier to reproduce.

Looks nearly as I would like it.
If only I could specify a new block without adding a line without tabstops
then I would be very interested in these elastic tabstops.
Currently, whenever I change variable or parameter names
I have to (re)align manually which would be automatic with ET.

The other drawback of ET is, that all alignment is gone if you
view the code in an editor that does not support ET.
But if it would become more common, this issue may go away over time...

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other