Lazarus
Miscellaneous => Jobs => Topic started by: Graeme on January 13, 2016, 03:59:29 pm
-
Hi,
If I was to create a bounty to have this implemented in Lazarus (and
hopefully somebody has the skill and time to implement it), what would
the cost be? I'll be funding this personally as Elastic Tabstop support
has been on my Lazarus wishlist for years. The algorithm of Elastic
Tabstops is pretty simple, I just don't know what would be involved in
modifying Lazarus's TSynEdit component to support this.
Some Elastic Tabstops (ET for short) background:
Elastic Tabstops homepage:
http://nickgravgaard.com/elastic-tabstops/ (http://nickgravgaard.com/elastic-tabstops/)
Visual Studio add-on:
https://www.alwaysaligned.net/ (https://www.alwaysaligned.net/)
This also shows a nice animated image of what ET does to source code
jEdit, Gnome's gEdit etc also support ET.
ET is a replacement for TAB and Space indentation. It is a age old
argument which I don't want to go into here... All I can say is that ET
is in my personal opinion by far the best option of the lot. jEdit has
been supporting it for years, and it is immensely useful with source
code, CSV files, SQL, XML etc. I've personally used jEdit with ET
enabled for almost a year now, and it rocks!
Basically ET's representation of a tabstop is similar to that found in a
word processor (eg: MS Office, LibreOffice). The size of the Tab can
vary. On the flip side, programmer editors and IDE's often hard-code a
Tab size to a set number of spaces, and this size is applied everywhere.
Programmer editors in turn also limit you to only using monospace fonts.
With ET, the code is grouped into columns and each column can have a
variable Tab size (normally defined in pixels).
It has many benefits like using variable width fonts and still keeping
code perfectly aligned or indented. It makes reading column data like
CSV or SQL files very easy. Because it normally uses a single Tab to
indent or align code, the file size is reduced too - not sure if this
helps with compiler parsing speed. End-users can configure the threshold
and the amount of indentation (in pixels) so if you are a 2-space indent
guy, with ET you can still make your code look identical to what it was
before. If you like a bigger indentation, configure it with a larger
indent - the source code number of TAB characters will still stay the
same regardless, so different settings per developer doesn't cause
source code repository whitespace diffs (unlike Space or static TAB
indentation does).
More feature complete ET implementations also support converting Space
indentation files to/from ET. But I'm not really interested in this
ability for the bounty. Gnome's gEdit had ET plugins that showed this
ability and it actually worked pretty well though. I'll be doing a once
off conversion of my source code to ET style indentation and then keep
it like that.
You are welcome to read the ET homepage for further information (I
suggestion you do, if you are interested in this bounty). I even
recommend you download the Java .jar file which implements a mini editor
with ET support so you can try it yourself, or run jEdit and enable ET
support in the settings.
So for those knowledgeable of TSynEdit, how much effort would it be to
implement Elastic Tabstop support in Lazarus IDE, and what would be your
estimated cost? Hopefully I can afford the cost, because I would really
love ET support in Lazarus. ;-) The resulting implementation would
obviously be shared back to the Lazarus project and hopefully get
accepted in the repository.
You can reply here in the mailing list, or reply in private if you want.
If you need any more information, just let me know.
Regards,
- Graeme -
-
Graeme,
Did you ever get a response (obviously not on this forum). I have no knowledge of the SynEdit component, but this looks interesting and I wondered if someone was going to implement it.
Also, does your fpGUI toolkit support it with the memo component? I might switch to fpGUI just for that feature :)
-
Did you ever get a response (obviously not on this forum).
Martin Fr. mentioned in the Lazarus Mailing List what is required, though I didn't understand much of it. Nobody seems interested in implementing this in Lazarus though. %)
Also, does your fpGUI toolkit support it with the memo component? I might switch to fpGUI just for that feature :)
Three weeks ago I actually posted some screenshots of my latest work on Elastic Tabstop support and fpGUI widgets. I've been working on adding support for the Memo and TextEdit widgets. The rendering to the Memo is perfect already, but because the Memo has no idea about TAB characters, the cursor movement is still incorrect. I'm working on solving that, then moving on to the TextEdit - which is the actual component I'm looking forward to using ET with.
Here are some screenshots with various ET parameters changed (sliders on the right). Each screenshot is annotated to explain what it is showing. An animated GIF would probably have been a much better visual example. All aligned code (in the middle or end of a line) is done simply by using one TAB character, ET does the rest.
-
And here is the last screenshot using a wacky proportional font - Comic Sans. Everything still indents and aligns perfectly.
I can't wait to start coding with much better looking proportional fonts.
-
Assuming I've understood correctly
I don't have time to do this as you know - but maybe some sort of modified string grid used as an editor -
or spreadsheet setup with single character width columns or something.
Perhaps you could have multiple tab controls at various rows to control set depth blocks.
(writing a spreadsheet from scratch isnt that
hard so you may not need to get bogged down with existing code if anyone wanted to try that.)
...just jamming a little on the idea.
-
The elastic tabstop URL seems to talk about hard tab characters only. I despise hardtab characters in plain text, and it would make text hard to edit with other editors, so that would be a nono for me. Anything but digging up that corps.
If you do it, you do it right, and don't reintroduce a pseudo character that most people considered a pain and a left over of mechanical typewriters and 1970's first implementations of Unix configuration files.
A more sane implementation would automatically detect aligning colums, and move whole blocks at once. Requires more syntax awareness, and is more complex, but does not change the basics of the disc format of textfiles.
-
Assuming I've understood correctly
I don't have time to do this as you know - but maybe some sort of modified string grid used as an editor -
or spreadsheet setup with single character width columns or something.
I'm afraid you totally misunderstood the workings of Elastic Tabstops. All you need to implement ET is a text control that allows setting tab widths in pixels (preferred, and to get the full benefit of ET), and the most importantly, you must be able to set multiple tabstop locations of varying widths per line. Just like you can do with MS Word or LibreOffice. eg: line 1 has a tabstop is at 1cm, second tabstop is at 2.5cm. Line 2 has a tabstop at 1cm and a second tabstop at 2cm.
eg: You set up ET to default tab widths to say 50px. But when it needs to align blocks of text, it will adjust any subsequent tab positions so text is perfectly aligned.
The reason ET prefers using pixels for tab widths is because then you can use proportional fonts too, not just monospace fonts.
-
The elastic tabstop URL seems to talk about hard tab characters only. I despise hardtab characters in plain text, and it would make text hard to edit with other editors, so that would be a nono for me.
It's not nearly as bad as you make it out to be. These is nothing wrong with using a TAB (U+0009) character for the purpose it was invented - tabulating text. Using spaces on the other hand to indent and align text is really the "odd" behaviour.
I've worked with two editors for over a year, editing HTML, JavaScript, CSS, SQL and SQL DDL. One editor supported ET, the other didn't. I've edited the same text it both, and it's really not that bad. Sometimes all that is needed to make the text look much better in the editor that doesn't support ET, is to tweak the tabwidth slightly. eg: from 4 space tabwidths to 6 space tabwidths. It's not perfect, but already made a massive difference.
Indentation is exactly the same between both ET and non-ET text. ET only kicks in when in comes to aligning text blocks. So if you don't align text (eg: comments at the end of a line of code, data types etc) then you will not see any difference.
What I really like about using TAB (U+0009) for indentation, compared to spaces, is that the text can be rendered differently for each developer - depending on their indentation size preference. Such a preference does not affect the actual text file at all. Some developers like a 1 space indentation, others 2 spaces. I like about 3-4 spaces. My previous screenshots showed such a preference change. When working with space indented text (like most Pascal code), you are unfortunately stuck.
Then the biggest benefit of ET for me at least, is giving you the ability to use proportional fonts - which on avg is much better looking that monospace fonts.
-
The elastic tabstop URL seems to talk about hard tab characters only. I despise hardtab characters in plain text, and it would make text hard to edit with other editors, so that would be a nono for me.
It's not nearly as bad as you make it out to be.
Either there are hardtabs in the textfile or there are not. Whole generations of programmers despise hardtabs, and with reason.
These is nothing wrong with using a TAB (U+0009) character for the purpose it was invented - tabulating text. Using spaces on the other hand to indent and align text is really the "odd" behaviour.
They were invented because of the hard tabs on the mechanical type writer. But that is exactly what the ET guy hates. He repurpose things for something else.
I've worked with two editors for over a year, editing HTML, JavaScript, CSS, SQL and SQL DDL. One editor supported ET, the other didn't. I've edited the same text it both, and it's really not that bad. Sometimes all that is needed to make the text look much better in the editor that doesn't support ET, is to tweak the tabwidth slightly. eg: from 4 space tabwidths to 6 space tabwidths. It's not perfect, but already made a massive difference.
That might be acceptable for you, but this is exactly what I dislike. Editability in other editors and diff tools (!) should not be compromised, most notably plain notepad (and no, wiggling with their local configuration to at least make it look half decent doesn't count, specially if you have to do that _each_ time again).
So let's agree to disagree on the allowability of hard tabs.
-
Either there are hardtabs in the textfile or there are not.
I never said otherwise. So at least we agree on something.
Whole generations of programmers despise hardtabs, and with reason.
And the opposite is true as well. The Spaces vs Tabs debate is as old as any programming language.
They were invented because of the hard tabs on the mechanical type writer. But that is exactly what the ET guy hates. He repurpose things for something else.
Please read the Elastic Tabstops website again - you totally misunderstood what Nick says. All he was saying is to stop interpreting a hard Tab character at every location as x amount of spaces. Instead, treat them like word processors have been doing since the dawn of time. Preceding any text, they mean x amount of pixels. Between text, their value is determined by a block of text (aka a cell).
The Tab (U+0009) characters meaning has NOT changed. It still means to tabulate text. ET simply suggests improving the visual representation of that. No need to modify text files unnecessary, no need for duplicate Tabs (or spaces) to align text. This all boils down to less typing and an improved visual representation of your text.
Editability in other editors and diff tools (!) should not be compromised...
Oh, now you touched on another benefit of ET (an tab indented text in general) I haven't mentioned. Source Control (and diff tools) play really nice with Tab indented text files. So much less diff noise caused by whitespace characters.
So let's agree to disagree on the allowability of hard tabs.
Indeed. This thread was not about the age old Spaces vs Tabs flamewars. Each for their own. This thread was me raising a bounty for implementing [optional] ET support in Lazarus.
Just for fun... ;)
http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/ (http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/)
-
Just for fun... ;)
http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/ (http://lea.verou.me/2012/01/why-tabs-are-clearly-superior/)
The biggest issue with tabs is "Tabs can be personalized".
Even worse, they ARE personalized, and they ARE personalized differently by every user/application.
That's why a code written by a one person, could look awful for another.
(I've to deal with that on daily basis, where a SQL code written i.e. in Notepad++ or whatever other editor looks misaligned in MS SQL Studio).
That's obviously not an issue for spaces. As article says "Spaces are the best choice for aligning".
The consistency in how spaces look to the end user, actually make them a better option for collaboration. At least what you see is what others will get :)
-
Spaces are the best choice for aligning, rather than indenting.
And I think that's what marco is saying. You should NEVER mix aligning with tabs and aligning with spaces in the same source. Choose one or the other but mixing them is BAD, very very bad. And for source-editing you would choose spaces because "Spaces are the best choice for aligning". When I enable tab in an editor and go typing I never know when there is really space-alignment or tab-alignment and then I always "loose" my cursor (it jumps unexpectedly when encountering tab-alignment). (Yes, I know I can make tabs visible... but still...)
That said... there is something to be said for elastic tabstops. I like the idea... but I would only use it for "normal" text-editing. Never for source-editing. But that's a personal choice.
-
The biggest issue with tabs is "Tabs can be personalized".
Even worse, they ARE personalized, and they ARE personalized differently by every user/application.
That's why a code written by a one person, could look awful for another.
It doesn't affect indentation. It only affects alignment. And the reason why Tabs get such a bad rap, is because of the idiotic way all [or most] editors implement (visualise) Tabs.... where a Tab character is equals to x amount of spaces.
ET doesn't change Tabs and Indentation - that works perfectly with any editor that supports hard Tabs. ET only addresses the issue where Tabs are used to align text (what you are complaining about). My suggestion is to download the very small ET Java demo, then write some code with indentation and aligned text and see how natural ET makes Tab character usage. Screenshots or an animated GIF doesn't do it justice.
http://nickgravgaard.com/elastic-tabstops/ETDemo.jar (http://nickgravgaard.com/elastic-tabstops/ETDemo.jar)
(I've to deal with that on daily basis, where a SQL code written i.e. in Notepad++ or whatever other editor looks misaligned in MS SQL Studio).
ps: There is an Elastic Tabstops plugin for Visual Studio.
That's obviously not an issue for spaces. As article says "Spaces are the best choice for aligning".
But spaces limit how I would like to see source code. eg: You might prefer 2 space indentation, Martin (from MSEide+MSEgui) prefers 1 space indentation, I prefer 4 or 6 space indentation (depending on how complex the code and how deep the nesting levels are). With spaced we can't display the same file in our preferred layout, but with Tabs (especially when ET is available too) you can - and all importantly, it doesn't require modifying the underlying text file.
-
You should NEVER mix aligning with tabs and aligning with spaces in the same source.
Indeed, and just to be clear, Elastic Tabstops doesn't suggest that either. ET makes aligning as natural as indentation.
there is something to be said for elastic tabstops. I like the idea... but I would only use it for "normal" text-editing. Never for source-editing. But that's a personal choice.
My suggestion is to download the very small ET Java demo, then write some code with indentation and aligned text and see how natural ET makes Tab character usage. Screenshots or an animated GIF doesn't do it justice.
http://nickgravgaard.com/elastic-tabstops/ETDemo.jar
Using ET is an absolute dream when working with CSV files, Sql DDL scripts, and yes, even source code. ;)
-
It's a nice demo. For small texts only. When using a larger text it becomes slooooow.
It would need to determine every (multiple) tab-indentation per block, for the whole text. If you want to gain some speed this would need to be cached for the current text because recalculating it on every view would be very time-consuming. As it is now it just shows the tabs just every 8 (or set) spaces (which is fast).
B.T.W. TSynEdit doesn't support proportional text (yet), does it? I can select a proportional font but that just looks ugly.
-
...
I'm fine with ET and other people using tabs, I'm just disappointed that "block-selection" got (is) broken in IDE.
I always treat a source code as 2d array of characters, that prevents me from using tabs ( that bring "holes" in this matrix)
-
It doesn't affect indentation. It only affects alignment. And the reason why Tabs get such a bad rap, is because of the idiotic way all [or most] editors implement (visualise) Tabs.... where a Tab character is equals to x amount of spaces.
You don't need any "tab" concept for that, elastic or otherwise. Input is space aligned, output is space aligned, and the only difference is the algo inbetween.
But spaces limit how I would like to see source code. eg: You might prefer 2 space indentation, Martin (from MSEide+MSEgui) prefers 1 space indentation, I prefer 4 or 6 space indentation (depending on how complex the code and how deep the nesting levels are). With spaced we can't display the same file in our preferred layout, but with Tabs (especially when ET is available too) you can - and all importantly, it doesn't require modifying the underlying text file.
IMHO if you really feel that way and consider variable hardtabs a possibility and sacrifice multi-editor general textformat principles, you might as well go the whole Oberon way and store the source as token streams or trees and forget about textual format.
-
It's a nice demo. For small texts only. When using a larger text it becomes slooooow.
Correct, and the author explicitly mentions that fact. The Java Demo was originally a Java Applet, with the sole intent to simply show the concept of Elastic Tabstops. It was never meant as a reference implementation. Different editors implement ET in different ways. jEdit for example supports ET, and it is fast even on very large text files.
As for ET configuration, again the Java demo was meant to show the concept only. My own fpGUI implementation and test application of ET makes it very easy to configure the default indentation size and padding size - as my earlier screenshots showed (trackbars on the right).
B.T.W. TSynEdit doesn't support proportional text (yet), does it? I can select a proportional font but that just looks ugly.
I would guess not. Simply getting ET support with a mono spaced font would at least be a good starting point.
-
I'm just disappointed that "block-selection" got (is) broken in IDE.
I'm not surprised. Tab support in Lazarus IDE was broken for years before I started raising some Mantis reports. In fact, Tab support in Lazarus is still pretty broken. Maybe some blame should go to CodeTools (whichever one does code completion).
-
I'm afraid you totally misunderstood the workings of Elastic Tabstops. All you need to implement ET is a text control that allows setting tab widths in pixels
Ahh .. I see.
You mean postscript.
Sadly the world has been crippled with microsoft rubbish for 30 years making a decent interface
almost impossible.
Perhaps super sized kerning on variable width fonts...
Hmm... how about a font with multiple pixel widths for whitespace characters and everything else
the same... again it would need work but maybe it could come close and wouldn't need to have
compatibility issues. Different blocks of text could use different combinations of character widths.
I'm still unclear why limited pixel spacing in a microsoft world is needed though but I guess
others have seen the benefit.
-
You mean postscript.
...snip...
Perhaps super sized kerning on variable width fonts...
Huh? Sorry I completely lost you there. ET doesn't require any special fonts or rendering API's. It also doesn't need tab stops defined in pixel widths, though it is hugely beneficial. eg: jEdit doesn't use pixels to define tab widths, it uses spaces (like most editors). Yet they made it work for ET. The down side - you are limited to mono-spaced fonts only. When tab stops are defined in pixels, you get the full benefit of ET - more accurate indentation, more accurate alignment and the use of proportional (variable width) fonts.
-
Seems Graeme dont need ET for ATSynEdit component? I could help here.
-
A partial working solution is on mantis
https://bugs.freepascal.org/view.php?id=9650