Bug 130229

Displaying (! not reformatting) tabs on-fly as spaces to reach next "column" of text is old and good idea. Already implemented.

But keeping distinct blocks of text separated by newlines, and keeping separate "column" definitions for each such block, well, isn't it an overkill for text editor (not processor, like KWord)?

a) do you really feel the need of such feature (I mean separate blocks with their own tab width)
b) how do you like to implement and keep the data -- definitions of tab-width cannot be kept with the text file, so where? What if somebody loose the tab-file (Python fans will love this ;-) )?

I believe that there is no additional information that needs to be stored.
Instead it takes the "displaying tabs on-fly as spaces to reach next 'column' of text" idea to the next level by allowing each "block" of text (separated by new lines) to have its own column calculations.

Personally, I think elastic *tabs* are a bad idea. Our own coding policy (most of my use of KATE is via KDevelop; plus a lot of editing of shell scripts in Kate) is "do not use tabs", precisely because people use such a variety of editors (MSDEV, VI[M], Visual SlickEdit, KDevelop, etc).

Now, if KATE(Part) were smart enough to insert an appropriate number of *spaces* (space-indent on, of course) so that I wouldn't have to mess with combinations of several tabs and spaces, that would be valuable.

I also have to disagree with monospace being outdated; At the moment, I have more Konsole sessions open, by far, than all other open applications combined. Terminals are NOT outdated.

Personally I hate space-indent. IMHO, the best way is to add new option "Elastic tabstops" in counterpart to space-indent and "classic" tabs.

i think there are some misunderstandings about the “elastic tabstops” concept.

it really helps to read the linked page, but a small summary:

* calculate the position of each tabstop for each block of text (seperated by lineas containing only whitespace)
* display these tabstops using the capabilities of the ui rendering library, not with spaces (so that proportional fonts can be used, and no glitches occur like the user being able to select individual nonexistant spaces or something)

----

a first step would be to implement an option for kate’s “Align dynamically wrapped lines to indentation depth” feature which allows to let kate align the content with the last tabstop instead of the indentation.

(so wrapped parts of a line beginning with “\t•\tBlah Blah” align with the position after the last tab instead of the first)

here the position of this function:
http://websvn.kde.org/trunk/KDE/kdelibs/kate/render/katerenderer.cpp?view=markup#l703

(also, the Qt::Dense4Pattern should be replaced by a semitransparent* color, the times of monochrome patterns are gone)

*simply use the color, which is 25% on the background-color to foreground-color gradient

We wont implement this, that will kill any interoperability with any other sane editor.

wait, what?

since when did adding optional features “kill interoperability”?

did i slip somewhere and demanded it to be implemented as the one and only way to handle tabstops?

Hi flying sheep, it's not that we did not consider this feature. In fact, there was a GSoC proposal about it, we (several developers) had a close look at this feature, and finally decided that it has rather low priority for now for several reasons. First, while the feature might be very useful for programmers, it's not necessarily for the rest of our users. Since there are lots of other things to be fixed and worked on, we decided to not implement this for now. Next, even if we decided to implement it, someone (probably of us) would need to do the work (maybe one week fulltime?).

Even if the report stayed open as e.g. NEW, the feature still would not be implemented the next years, at least not by us. Hence, if someone provides a clean implementation, we are happy to accept it (might require quite some work). But simply having hundreds of open reports is not really improving the situation.

We try to keep our bug list manageable, and have to decide for (currently 800 reports) what to do with it. We have decided for now to not implement this feature request, so I'll close as LATER...

In my opinion it's better to communicate "No, we won't implement this" than "yeah, maybe, in 10 years or so". :)

Still, thanks for your feedback, at least we are aware that this feature seems to be interesting for some users.

> In my opinion it's better to communicate "No, we won't implement this" than "yeah, maybe, in 10 years or so". :)

yeah, that’s exactly why i was unhappy, nothing more: if it would have stayed closed as WONTFIX, that would mean that even if someone would provide you with a working, clean implementation, someone would come along and deny it with the words “it was closed WONTFIX for a reason, go away.”

been there, seen that.

*** This bug has been confirmed by popular vote. ***

It's been 10 years, so it's only fair to revive this report :)

Which class/widget would be the best to control such behaviour?

I noticed that KTextEditor::View is used quite a lot, but after some looking around, it seems that it's an abstract class, but kate sources don't clearly indicate what actually implements it. Could anyone help?