I don't know about you, but I like this idea implemented in Java 7 and later.

http://jasdhir.blogspot.co.uk/2016/11/using-underscores-in-literals.html

I always find it hard to read long numeric literals.

Alternatively, without needing compiler changes, the IDE's and programmer editors should become more clever in how they display source code (think Elastic Tabstops), and automatically display numeric literals with slight increase in [render] spacing between certain number groups. Binary literals could be grouped every eight digits, whereas Hex could be grouped every 4 and Decimals every 3 digits. The age old rule of programmer source code always being in a mono-spaced font is ridiculous for this day and age.

Regards,
Graeme

I like the concept, but, if I'm using a constant that goes beyond the millions, I'd add a comment to what the number is in US format, and tag on what exactly it means, or make the variable name itself mean something. Because reading

const maxLongint = $7fffffff;

or

const maxLongint = 2147483647;

is a bit of a pain, I agree.

That said, underscores aren't what I'd use.

I love the idea of the IDE (ANY IDE, not just Pascal based) doing some kind of code highlight for large numbers. Something simple, like underlining every other group of 3 in large numbers, or every other hex pair, or every 8 binary set.

As for the mono-spaced, no, not ridiculous. If memory serves me correct, I believe you're as old-school as I am when it comes to code (My teeth cut on Vic-20), but I've always preferred mono-spaced fonts in my IDE versus variable width, JUST on the primary basis of legibility of the code itself, ignoring the 'gravy' of lining up text within the code. I always terminal/system/consolas, even in Notepad/PSPad. I barely tolerate variable width font in GMail as I can't change the font easily (But you've sparked an idea >:] ). Figuring out if I'm using a capital I versus a lower l versus a | is quite annoying (Capital EYE versus lower ELL versus pipe). Most of the apps I write (for myself) are list based, or require special formatting are typically fixed width as aligning text is much easier, and I don't have to code special considerations for W and 1 width differences. Forget about the form UI, but even lining up variable declarations and definitions, procedure, function declarations within classes, much easier with fixed width.

On Mon, Nov 21, 2016 at 9:46 AM, Graeme Geldenhuys <

Graeme Geldenhuys wrote

The age old rule of programmer source code always being in a mono-spaced font is ridiculous for this day and age.

Why?
I like monospaced fonts for code very much.

Code is not a novel or a newspaper where you read
a lot of text from top down to the end in a linear manner. Instead, alignment is very important to make code more readable. Monospaced fonts make it much easier to align code and make a lot of things align 'automatically'.

I even align procedure headers like the following where all variables and all types start at the same column
(which may not be visible in this email if you use proportional fonts ;-). Please copy it to notepad or into Lazarus Editor in this case):

---------------------------------------------------------------------
procedure TForm1.FunctionListGetHintSize(Sender : TBaseVirtualTree;
                                          Node   : PVirtualNode;
                                          Column : TColumnIndex;
                                      var R      : TRect);
---------------------------------------------------------------------

and I align the 'MaskFilter' variable in such a for loop:

--------------------------------------------------------------------- for i := Low (MaskFilter) to
High(MaskFilter) do
---------------------------------------------------------------------

and I like such an aligned declaration

---------------------------------------------------------------------
function  FileCompareName     (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareDate     (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareSize     (Datei1,Datei2 : PFileTyp) : SizeInt;
function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInDir     (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInBranch  (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirName       (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareFilesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareBytesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInDir    (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirName      (Dir1,Dir2 : PTreeTyp) : SizeInt;
---------------------------------------------------------------------

much more than a non-aligned:

---------------------------------------------------------------------
function  FileCompareName (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareDate (Datei1,Datei2 : PFileTyp) : SizeInt;
function  FileCompareSize (Datei1,Datei2 : PFileTyp) : SizeInt;
function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  DirCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
function  TreeCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
---------------------------------------------------------------------

You can see imeditately that many functions have the same parameters and all result in a SizeInt. In the non-aligned version this is harder to spot.

I guess Graeme meant to make non-monospaced font look like monospaced in Lazarus editor which currently doesn't work (it looks very ugly).  
V.
______________________________________________________________

Graeme Geldenhuys wrote

The age old rule of programmer source code always being in a mono-spaced font is ridiculous for this day and age.

Why?
I like monospaced fonts for code very much.

Code is not a novel or a newspaper where you read
a lot of text from top down to the end in a linear manner. Instead, alignment is very important to make code more readable. Monospaced fonts make it much easier to align code and make a lot of things align 'automatically'.

I even align procedure headers like the following where all variables and all types start at the same column
(which may not be visible in this email if you use proportional fonts ;-). Please copy it to notepad or into Lazarus Editor in this case):

 ---------------------------------------------------------------------
 procedure TForm1.FunctionListGetHintSize(Sender : TBaseVirtualTree;
                                          Node   : PVirtualNode;
                                          Column : TColumnIndex;
                                      var R      : TRect);
 ---------------------------------------------------------------------

and I align the 'MaskFilter' variable in such a for loop:

--------------------------------------------------------------------- for i := Low (MaskFilter) to
         High(MaskFilter) do
---------------------------------------------------------------------

and I like such an aligned declaration

 ---------------------------------------------------------------------
 function  FileCompareName     (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  FileCompareDate     (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  FileCompareSize     (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirsInDir     (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirsInBranch  (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirName       (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareFilesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareBytesInBranch(Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirsInDir    (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirName      (Dir1,Dir2 : PTreeTyp) : SizeInt;
 ---------------------------------------------------------------------

much more than a non-aligned:

 ---------------------------------------------------------------------
 function  FileCompareName (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  FileCompareDate (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  FileCompareSize (Datei1,Datei2 : PFileTyp) : SizeInt;
 function  DirCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  DirCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareFilesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareBytesInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirsInDir (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirsInBranch (Dir1,Dir2 : PTreeTyp) : SizeInt;
 function  TreeCompareDirName (Dir1,Dir2 : PTreeTyp) : SizeInt;
 ---------------------------------------------------------------------

You can see imeditately that many functions have the same parameters and all result in a SizeInt. In the non-aligned version this is harder to spot.

+1
Anything BUT a mono-spaced font for program code is ridiculous, even in this day and age...

We are programming in Pascal, which is neither case-sensitive (like for example C) nor does it make it whitespace significant (like Python), allowing for a much more readable code than most other languages out there, as you can easily format code in a way that is more human readable. The machine (compiler) doesn't care for that...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

heh.. Not really, as GMail uses variable width fonts by default. ;) Imma gunna feex dat.

On Mon, Nov 21, 2016 at 11:05 AM, Jürgen Hestermann <

wrote:

---------------------------------------------------------------------

Stephen Chrzanowski wrote

but I've always preferred mono-spaced fonts in my IDE versus variable width, JUST on the primary basis of legibility of the code itself, ignoring the 'gravy' of lining up text within the code.

Hence I mentioned "think Elastic Tabstops" which solves that problem for proportional and monospace fonts. I've used Elastic Tabstop support in jEdit (java based editor) for the last 3 years, and it works brilliantly.

Here is a fpGUI newsgroup post (printed to PDF), where I implemented basic Elastic Tabstops (ET) support in a homegrown text editor with the ability to play around with ET user-defined parameters. Also see the screenshots at the end where the last two uses proportional fonts.

http://geldenhuys.co.uk/~graemeg/temp/elastic_tabstops_demo_landscape.pdf

Elastic Tabstops homepage:
http://nickgravgaard.com/elastic-tabstops/

A nice overview of ET:
http://tibleiz.net/code-browser/elastic-tabstops.html

Anyway, I didn't mean to make this message thread about ET, but I guess using something like ET (more intelligent editors) could solve the problem nicely without any compiler changes.

Regards,
Graeme

Jürgen Hestermann wrote

Why? I like monospaced fonts for code very much.

See my reply to Stephen. More intelligent editors can let you use monospaced and proportional fonts with ease - yet you don't loose code alignment, indentation etc. Elastic Tabstops do just that. It's simply about editors becoming more clever about there text rendering instead of forcing everything into a grid of character cells.

Plus proportional fonts overall look much better than monospaced ones. ;-)

Regards,
Graeme

Vojtěch Čihák wrote

I guess Graeme meant to make non-monospaced font look like monospaced in Lazarus editor

No I didn't mean would be disastrous. Take a look at my reply to Stephen, and follow the links mentioned there and see the screenshots in the PDF linked.

Regards,
Graeme

Am 21.11.2016 18:27 schrieb "Graeme Geldenhuys" <

itself,

While elastic tabstops might be nice and good I personally definitely wouldn't want anything but a monospaced font in my editors (one of the first things I change in Notepad++ is the idiocy to use Comic Sans for comments). That's not only due to code alignment (which would indeed be solved by elastic tabstops), but also due to the ability to easily compare different names simply based on their visual length without having to decide whether the difference is due to the name or the different sized characters.

Regards,
Sven

In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]

IMHO editors should be like network protocols. Liberal in what you accept, and conservative in what you write.

IOW I don't like editors that store in formats that are nearly useless in other editors.

Marco van de Voort wrote

IOW I don't like editors that store in formats that are nearly useless in other editors.

Elastic Tabstops (ET) only does rendering of the text - based on two user defined preferences. The underling file doesn't change because of user preference changes. The underlying file is just a TAB(U+0009) indented file - like most programming language style defaults (Object Pascal for some reason being the exception - but it doesn't need to be).

Any text editor worth their salt can display a TAB indented text file. An ET capable editor simply does a much better job and with more flexibility.

Anyway, again, my discussion wasn't meant to be about ET specifically, but simply that text editors could become more intelligent by automatically adjusting the spacing of long numerical literals (without affecting the underlying file - like ET capable editors achieve).

Regards,
Graeme

Sven Barth wrote

but also due to the ability to easily compare different names simply based on their visual length without having to decide whether the difference is due to the name or the different sized characters.

I don't think you fully understand what Elastic Tabstops (ET) does. Indented and aligned text are possible with or without monospaced fonts. That's the beauty of ET.

The following website gives very nice visuals and detailed overview of what ET can and can't do.

http://tibleiz.net/code-browser/elastic-tabstops.html

Based on your quoted message above, could you give an example of where you think ET will fail with a proportional font?

Regards,
Graeme

Sven Barth wrote

but also due to the ability to easily compare different names simply based on their visual length without having to decide whether the difference is due to the name or the different sized characters.

And here is an example of the exact problem, but when using a monospaced font. The spelling error is spotted much easier when using a proportional font.

View the following URL and search for “Proportional fonts can make it easier to spot typos.” - it’s about 3/4 down the page.

http://input.fontbureau.com/info/

Regards,
Graeme

IOW I don't like editors that store in formats that are nearly useless in

other editors.

I total agree with this statement, proportional editors are only good if you are the only one who will ever look at the code, if anyone else EVER looks at it, it's just a giant mess, you can't put snippets of it in pastebin for ask for help, or really collaborate in anyway with anyone else without manually re-formatting it for a monospaced font, and there is really no point in even bothering. I find Consolas VERY easy on the eyes and have no problems organizing my code with it. I, l, 1, AND | are all distinctly different with it as well as 0 and O. I have a REAL pet peeve about font's that these characters look identical, unfortunately Arial is one of them, and guess what font stock installations of windows use.. and the VAST majority of windows users have no idea it can be changed, never mind how to change it.. My son's teacher sent home spelling words typed in Arial and my son was spelling Illusion - i i i u s i o n because it was just not clear what the characters were. When writing code we have a LOT of variables and such that are not normal readable words so it's a really bad idea to have a font with any questionability in what the characters a lot of proportional font indent corrections only work if your font is a particular size, if you change your mind and decide you are getting older and now need a larger font than you did 10 years ago, now all your code that used to look good, is all misaligned. The only way code will be properly aligned all the time, in any editor, at any size is to use a monospaced font, and do not use tabs at all, set your editor to insert spaces for tabs. The only thing that ever looks good all the time to everyone is a nice grid of character cells. Even if an editor COULD make it come out right with a proportional font, you are back to now having code that only one person can ever read, making it useless, so why bother with the effort at all... it's also impossible to autocorrect every situation with a proportional font.. for example:

P_Range[1,0]:=0;
I_Range[1,1]:=0;
W_Range[2,0]:=0;
R_Range[2,1]:=1;

With a monospaced font, they are all perfectly aligned, but with a proportional font, there is nothing the editor could do automatically to fix this. Sure you could put some space between the variable and the [ and try to adjust that space in a reverse proportional method, but that doesn't make it look right, and you CAN'T stick any space in the actual variable name to make all the _Range align again once the initial proportional letter has fouled everything up. I have been programming for a long time, (also started with a VIC20) and I just don't see how structured programming can be done effectively with a proportional font.. you will spend more time trying to force the proportional font to look good than actual programming. As it mentions on the Freepascal wiki, pascal itself doesn't require any formatting, you can put your whole program on one long line if you want, but no one else will ever understand it. The formatting is for our benefit, so why would you use some kind of editor that now takes all your nice formatting and saves it in a way that requires a specific editor to read. The spacing and formatting is much more important that the actual reading of individual 'words' in a program, you need to identify the variable you are working on quickly and follow the structure accurately, thus monospaced fonts are far and away the best choice for this.

On Mon, Nov 21, 2016 at 9:46 AM, Graeme Geldenhuys <

I find it a made up problem, inspired by sales department.

The site shows CC-card and SSN number stored as numerics. I doubt there's ever a task that actually needs such storage (since both numbers should be considered as a set of characters ie strings).

Maybe its a new feature that will inspire people to use more anonymous constants.
They looked ugly before, but look how cute they look now if underscores.

Having pure-functions available for pascal constant expressions is far more preferred than underscores.
And it will also might make them even more readable and flexible.

thanks,
Dmitry

I use notepad++ Vertical editing ALL THE TIME, you cannot do vertical editing effectively with a proportional font. For those who aren't familiar with it, you can hold down ALT and highlight many lines vertically making a very tall cursor, you can then start typing and what you type will be on all lines with the tall cursor.. thus you can very quickly and easily shift entire blocks over, or even fix something on many is very helpful when you have something that used to be inline and now you want to make a procedure out of it for example.

Yet another daft idea from java. Is there any other place in any language (programming or natural) where underscored are used in this way? Any long list of digits will represent a string anyway. My library card had a field with 9 digits, but that sure ain't a number.

James Richters wrote

I use notepad++ Vertical editing ALL THE TIME, you cannot do vertical editing effectively with a proportional font. For those who aren't familiar with it, you can hold down ALT and highlight many lines vertically making a very tall cursor, you can then start typing and what you type will be on all lines with the tall cursor.. thus you can very quickly and easily shift entire blocks over, or even fix something on many is very helpful when you have something that used to be inline and now you want to make a procedure out of it for example.

The editor can just switch to a monospaced font when the vertical/column selecion-mode is toggled, this is what Eclipse does. BTW SynEdit also supports column selection, it's just not available in the menu. In the Options Dialog you can assign key mappings to Column and Normal Selection Mode.

-Flávio

In our previous episode, Graeme Geldenhuys said:

Yeah, that's what I mean. One of the reasons why hardtabs are such pain is because you need settings to view a file properly.

I've worked with quite some C/C++ and Java IDEs, but can't really remember any defaulting to hardtabs (some did default to LF-only files though, another PITA)

Anyway, again, my discussion wasn't meant to be about ET specifically, but simply that text editors could become more intelligent by automatically adjusting the spacing of long numerical literals (without affecting the underlying file - like ET capable editors achieve).

If you can do it in IDE, do it in IDE, indeed. A popup with some separators inserted and/or multiple number systems would be the way to go in this case I guess.

Flávio Etrusco wrote

The editor can just switch to a monospaced font when the vertical/column selecion-mode is toggled, this is what Eclipse does.

Exactly, and if you are prefixing something or inserting something in multiple lines that all have the same text, even in proportional fonts (and the way ET aligns them), it will work just fine.

I'm fully aware than the idea of using proportional fonts for coding or most text editor work sounds alien - simply because that is how it was done for decades. But times have changed, some editors have advanced, some editors have implemented more intelligent ways of working with text and fonts - opening up more possibilities to use better looking fonts. Eclipse and IntelliJ IDEA (surprisingly both implemented in Java - coincidence or not) has raised the bar considerably when it comes to intelligent text (source code) management. Both Eclipse and MS Visual Studio support Elastic Tabstop plugins too.

Anyway, time permitting, I'll play with my experimental text editor and see if I can implement a more intelligent way of displaying long numerical literals with group spacing (visual rendering only - no changes to the underlying file).

Regards,
Graeme

Marco van de Voort wrote

If you can do it in IDE, do it in IDE, indeed.

Indeed. This discussion clearly revealed that having a smarter IDE or text editor is the preferred way to go, compared to implementing a compiler change that supports underscores (like the original article I referenced).

Thanks to all that contributed to this discussion.

Regards,
Graeme

James Richters wrote

I, l, 1, AND | are all distinctly different with it as well as 0 and O. I have a REAL pet peeve about font's that these characters look identical,

You do realise that not all monospaced fonts are equals. Some monospaced fonts are terrible for programming source code too. Some monospaced fonts don't make much [if any] distinction between those tricky characters either.

Then you get fonts like "Input", which actually allows you to configure the fonts before you download them. You can choose how you want the 0 (zero), a, l, i etc rendering style to look like.

Go to the following URL and click "Customize your download". You can then configure various character styles (and even line spacing) before you download a customised font just for you. The choice is available for both monospaced and proportional versions of the Input font.

http://input.fontbureau.com/download/

So your "pet peeve" (which I also have) holds no merit in this discussion.

PS:
As for your comment about your son's homework. I've had the exact same issue at my son's school! I can't believe they (the teachers) can be so stupid.

P_Range[1,0]:=0; I_Range[1,1]:=0; W_Range[2,0]:=0; R_Range[2,1]:=1;

I prefer spacing between programming language symbols, even though I have syntax highlighting enabled too. So I would write the above as:

P_Range[1,0] := 0;
I_Range[1,1] := 0;
W_Range[2,0] := 0;
R_Range[2,1] := 1;

I normally use a monospaced font - Raize font to be exact - which is a bitmap based font.

But to give you an idea of what the above source code will look like in other editors. Take my code sample above, replace the spaces with single TAB (U+0009) characters. This not only reduces the file size, it also reduces the number of characters any parser needs to process (thus faster parsing and compiling). :)

See attached screenshots.

text_with_tabs_monospaced_font.png
This is viewed with EditPad Pro, using a monospaced font and the TAB size was set to be equal to 2 spaces in width. Other editors text to default TAB width to equals 4 or 8 spaces. Point is, the text will always align. EditPad Pro doesn't support ET.

text_with_tabs_Input-Sans_proportional_font_and_ET.png Here I used my experimental Elastic Tabstops enable text editor with a proportional font (Input Sans). Note that the text is still perfectly aligned. Also note that even though I use a proportional font, the 1 (one) and 0 (zero) characters are easily distinguishable from l, I, L, o and O letters. The 3rd note is that with ET, the minimum width and padding are defined in pixels, not [Space] character widths (like most editors do with TAB widths).

So this just shows that alignment can be achieved with or without monospaced fonts. Also that not all fonts are created equal. Just like not all monospaced fonts are appropriate for programming (tricky letters and numbers). Also not all proportional fonts are created equal - some are better suited to programming code than others. The "Input Sans" font is actually very nice for source code.

Regards,
Graeme

I am still not sure how exactly elastic tab stops work. I put standard tabs (#9) in each line and the editor aligns these tabs for adjacent lines?
What if an empty line is between such lines?
What if I want to start a new 'table' which is not related to preceeding or following lines?

In this example (where 'Param1' should align with 'Param2') ---------------------------------------------
if ProcedureA(FunctionA(Param1,
Param2),
true,
false,
false,
Shift=[ssAlt],
ErrorCode) then
ShowMessage('ERROR')
---------------------------------------------
I would put tabs before 'ProcedureA', 'FunctionA', 'Param1', 'Param2', 'true', 'false', etc. and 'ShowMessage' and 2 extra tabs on the start of the second line (with 'Param2'), 1 extra tab for the following lines?

I found an interesting discussion discussion about elastic tabstops with some cons here: http://softwareengineering.stackexchange.com/questions/137290/what-are-the-drawbacks-of-elastic-tabstops

Is there any other place in any language (programming or natural) where

underscored are used in this way?

In Ada at least since 1983.
http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html

2016-11-22 1:26 GMT+01:00 Gordon Findlay :

Dmitry Boyarintsev wrote

I find it a made up problem, inspired by sales department.

do agree that using constants is a very good idea, instead of hard-coded "magic numbers", but sometimes you use a value only once in your code, and a constant is simply overkill.

Here is an example of actual code I have:

  checksum := $B1B0AFBA - (checksum and $ffffffff);

Quickly look at that and tell me how many "f" are in the last hex value. Did I make a typo by adding to many or to few f's? Can't tell (monospaced font or not), so you have to carefully count that to be sure. Making small typos in such values could take hours to debug and find.

Now, lets look at the same code again, but formatted as mentioned in the Java blog. Quickly, how many f's did I type now in either hex value? Instantly you can see I made no typos.

  checksum := $B1B0_AFBA - (checksum and $ffff_ffff);

Group formatting of numerals - via a underscore or more intelligent text rendering by the text editor - would be very very useful to eliminate those subtle bugs. It's exactly the same as what syntax highlighting does - making reading and writing source code easier, and with less mistakes.

Regards,
Graeme

Yann Mérignac wrote

In Ada at least since 1983. http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html

:-D

Thanks for that Yann.

Regards,
Graeme

Jürgen Hestermann wrote

I am still not sure how exactly elastic tab stops work.

Think how a word processor (MS Word, LibreOffice Writer) interprets tabstops. Word Processors don't define a TAB as x width of Spaces or Pixels. But for some strange reason IDE's and Text Editors do!

In word processors a single TAB character can jump the cursor all the way to the right side of a page. Also you can have multiple tabstops on a single line, but each tabstop has a different width.

That is kind-of how Elastic Tabstops work, but in the case of ET, it decides the width of a tabstop based on a block of text and your Indentation and Padding preferences.

What if an empty line is between such lines?

ET works with text blocks, so an empty line would introduce the start of a new text block. The new text block might still fall under a previous indentation level though. I guess the best way to understand this is to try out the small Java application downloadable from the author's homepage.

In this example (where 'Param1' should align with 'Param2')

If you want something aligned or at the same indentation level, you simply need to insert a TAB character. ET will keep blocks of text indentation and aligned even if any text inside that block grows or shrinks.

I wrote your sample code in two ways. The first sample doesn't really take much advantage of ET, as all tab widths are the same (indentation). I enabled showing TAB characters so you can better see what I mean.

In the second layout example (lines 13-21) you will note that on line 15 the second tab is considerably larger than all other tabs. ET did that because the two parameters of FunctionA() fall into the same text block, so they get aligned equally.

Then for good measure, I loaded that same sample text into my experimental ET enabled editor and switched to a proportional font (Input Sans). Magically all indention and alignments are still correct. :-) That will still be true even for other wacky proportional fonts like cursive ones or MS Comic Sans etc.

I found an interesting discussion discussion about elastic tabstops with some cons here: http://softwareengineering.stackexchange.com/questions/137290/what-are-the-drawbacks-of-elastic-tabstops

hahaha... I love how a con is “fundamentally different concept”. How is that a con? Just because ET's implementation is different to how TABs were handled in text editors for the last couple of decades, doesn’t constitute it as a con - it’s an improvement to how TABs are interpreted and rendered on screen.

Regards,
Graeme

Now we're getting into the field of personal preferences, and EVERYONE and their neighbor on the internet is going to defend their personal preferences like a rabid dog over a piece of meat.

Looking at a screen all day long, comfortably, is ultimately up to the person sitting in the chair at that computer. For email, variable width fonts are alright (Although I've now changed that in gmail so I read email in a fixed-font family). For code, fixed font, terminal/consolas/system fonts for me, end of story, and if the IDE doesn't support it, I remove the IDE and look at something else. Taking another font that is variable width, and pretends to be monospace still irritates me, and is a distraction.

The goal of the developer is to setup the IDE so that they are comfortable using it for long periods of time, and use the system effectively. All these 'toys' that people write are fine, but, claiming that fixed font is of ancient ways, although true, has exactly zero bearing on the effectiveness of the development process. You're not going to write a better function because you're not using Arial.

This whole discussion is going towards discussing the "standards" of some web forum software forcing their tables to be a max of 1024 pixels wide, leaving a whack of white space, for the purpose of "readability". I'm a very strong opponent to it. I hate it. On my 2560x1440 screen, no text scaling, those sites look absolutely ridiculous when my browser is full screen. I have browser plugins that change the formatting on the tables/divs/CSS that change those sites around so I can view the way I want to, not the way they THINK is best for me.

On Tue, Nov 22, 2016 at 5:05 AM, Graeme Geldenhuys <

Graeme Geldenhuys wrote

The age old rule of programmer source code always being in a mono-spaced font is ridiculous for this day and age.

I think you are wrong. A programmer scans code most the time vertically or block by block and not horizontally and word by word as normal text. And for that a monospace font is much better suited because of the straight vertical character columns.
I know that this theme is off topic here but I thought somebody should express a different meaning.
I also don't like elastic tabstops much BTW...

Martin

Stephen Chrzanowski wrote

tables/divs/CSS that change those sites around so I can view the way I want to, not the way they THINK is best for me.

And there is no difference to that and an editor that supports ET. If you don't want to use ET, simply disable it, and go about your job as normal. In all cases where I've seen editors that support ET, they have chosen to disable ET by default - so as not to upset the apple cart.

I never suggested all editors use ET or nothing. I simply stated that if a editor is smart enough to support ET, it could go one step further and [optionally] support grouped numerical literals too. Obviously for text editors (or IDE's) that only support monospaced fonts and force all text into grid-like character cells, they will not be able to support the rendering of grouped numerical literals either.

Regards,
Graeme

Am 22.11.2016 12:14 schrieb "Graeme Geldenhuys" <

I think the difference a tab versus a couple of spaces makes (even if across a whole file or a whole project) will be insignificant and maybe even get lost in the noise that stems from disk caches and the multi tasking nature of today's operating systems.

Regards,
Sven

...

A programmer scans code most the time vertically or block by block and not horizontally and word by word as normal text. And for that a monospace font is much better suited because of the straight vertical character columns.

Agree. The idea that reading code is like reading a novel, was put forth by IMO a somewhat idiot, Rob Pike in this particular case, as far as I remember. His argument was that C code was easier to read_with_lots_of_underscores.

My counter argument was that underscores jump out like a symbol, like a minus sign, so you pollute the code with symbols, and there is enough space and symbols already littered throughout the code.

As for underscores in numbers, it is an interesting idea but I see delphi compatibility issues coming up.... any code you want to port has to be converted to non underscores, or delphi would have to implement the feature at some point. Another mode switch if check in the compiler, in possibly more than one place.

Sven Barth wrote

I think the difference a tab versus a couple of spaces makes (even if across a whole file or a whole project) will be insignificant

Well, for every byte in the file, the parser needs to figure out what to do with it. Less bytes, means less processing cycles - no matter how small. They do add up in the end when you have to parse some 1 million lines of code.

But there was also a reason I put a smiley face at the end of my post. [technically what I said is sound and true, but I have no metrics to prove it]

Regards,
Graeme

Lars wrote

As for underscores in numbers, it is an interesting idea but I see delphi compatibility issues coming up.... any code you want to port has to be converted to non underscores

Who in there right mind would ever want to move from Free Pascal to Delphi! The reverse is frequently done though. ;-)

Regards,
Graeme

Martin Schreiber wrote

I think you are wrong.

And you have all the right in the world to say that. Just like I would say I can't read your code at all - because everything is lowercase and with only 1-space indentation. Your coding style - your preference.

Each developer has their own preferences - I never argued that. I prefer to read code with 3-4 space indentation, and when debugging heavily nested code, I would even prefer 6-8 space indentation to help see blocks of text more clearly. If you don't like ET, simply don't use it. In every editor I've seen that supports ET, in was optional and disabled by default.

ps:
Take a look at this linked PDF and look at the second image. That was purposely done to mimic your coding style - 1 space indentation. All done by tweaking the ET preferences, and not actually changing the underlying file at all. :)

http://geldenhuys.co.uk/~graemeg/temp/elastic_tabstops_demo_landscape.pdf

ET allows each developer to apply their own preferences without the underlying files being modified. Perfect in an environment where many developers work on the same source code units.

Regards,
Graeme

Hi,

Now that the discussion moved from a potential compiler feature to coding style preferences, can we please move it to the fpc-other list?

Thanks,

Jonas
FPC mailing lists admin

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?

R.

To the topic:
 
Currently when I write the line (in Laz. editor):
 
const Num = 123456789;   
 
I can hover the identifier "Num" and I see tooltip:  
const Num = 123456789
/file/name.pas(x,y)
 
And there is no tooltip when I hover the "123456789".  
Maybe this is place for improvement.
 
Hovering the "Num" could show
 
const Num = 123 456 789
/file/name.pas(x,y)
 
while hovering the "123456789" could show just
 
123 456 789
 
V.
______________________________________________________________

I don't know about you, but I like this idea implemented in Java 7 and later.

http://jasdhir.blogspot.co.uk/2016/11/using-underscores-in-literals.html <http://jasdhir.blogspot.co.uk/2016/11/using-underscores-in-literals.html>

I always find it hard to read long numeric literals.

Regards,
 Graeme

The problem with your example "text_with_tabs_Input-Sans_proportional_font_and_ET.png"  is that the underscores and the word Range and the brackets are all out of alignment,  even though everything is re-aligned again with the :=  I prefer the array elements to also be aligned as well.   In my opinion this misalignment caused by the proportional font is more annoying than the monospaced font.

You forgot to consider how scanners work, i.e. how they check and skip spaces.

Here are some numbers:

Compiling Lazarus sources 'make clean all' 1249309 lines 3 times 0m51.682s
0m51.415s
0m51.698s

Lazarus uses indentation of 2, so replacing each double space with one tab saves 3.7mb. Compiling 3 times:
0m52.003s
0m51.294s
0m51.452s

This is a desktop system, so there is always a bit of noise. As you can see, the time difference is not measurable.

To estimate the potential speed up:
Replacing all multi spaces with one space saves 6.1mb. Compiling 3 times:
0m51.064s
0m50.733s
0m51.120s

It seems scanning the spaces costs about 1%.

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

Mattias

In case somebody is interested, the main loop for reading spaces is in
compiler/scanner.pas, procedure tscannerfile.skipspace;