Code Folding Updates

Christoph and me cleaned up the visualization of the code folding for KDE 4.8 a bit. In the snapshot, the left image shows the old behavior, and the right one shows the new behavior. The background highlighting appears as soon as you hover over the code folding bar. We hope you like it :) Mockups of how to make it even better are welcome, of course! You can try it by building Kate yourself, if you want.
Kate Code folding

22 thoughts on “Code Folding Updates

  1. Hello.

    You have intrigued me and I decided to give Kate a try. I’m writing HTML, CSS & jQuery code so I would like know if it is a good idea to use Kate (what is Kate generally used for?).
    I opened one of my files and tried code folding. Unfortunately it it not as good at it.
    Maybe is it a chance to improve it?

    And, what is your opinion on writing ‘front-end’ in Kate?

    1. Oh sorry. It rather can’t handle RegExp in the /…/ form:

      _service = {
      youtube: {
      urls: [/(http:\/\/www\.youtube\.com\/watch\?v=([\w-_]+))&?/],
      type: “youtube”
      image: {
      urls: [/.jpg$|.png$|.gif$/],
      type: “image”
      vimeo: {
      urls: [/(http:\/\/vimeo\.com\/groups\/\w+\/videos\/(\w+))&?/, /(http:\/\/vimeo\.com\/(\w+))&?/],
      type: “vimeo”
      flash: {
      urls: [/.swf/],
      type: “flash”

      This code is treated as a whole. That is you can’t fold youtube, image, vimeo and flash separately. If you inserted urls: “foo” in vimeo for example it would fold.

  2. If it can be faster, then I agree with this change to be the new default. But the rainbow allowed to visually see at all time where a block start and end. Now to show this, you have to mouse over the arrow.

    What do you think about having rainbow as an option but disabled by default and using the selection color?

    Also, as I wrote in the ctrl+scroll bug report, don’t you think page up/down should be kept as an option? I is more useful, more often than zoom. Even if zoom should stay the default for consistency. If the usability is greater than the consistency, then any feature removed should be kept as an option? Don’t you agree?

    (I just reverted the commits in my local branch for now, so someday I might write a proper patch, but it may take a while)

      1. We intentionally wanted to get rid of the rainbow colors.
        – 10 slightly different colors are not easy to differentiate
        – they never nicely integrated into Kate’s nor KDE’s color scheme

        The question is do you really need to have the information where a block exactly ends?

        I’m not in favor of adding the rainbow colors again, so other suggestions are welcome.

        1. The only thing the rainbow colors did for me was to distract from the important part of the widget, the text.
          If you look at the left image, I guess 90% of all people will first look at the left colored bar, which is actually not the important content, look at the right, and the text plays the major role. (if you don’t hover over, this is even more obvious, but as we color both bar and text now on hover, still text is marked most important)

          1. Do you really get distracted? What’s the problem of people looking at the left bar first? It’s a code editor and it will be used to development, it really doesn’t change anything in terms of production having the bar as we have.

    1. You don’t loose a features, because you can still use shift+scroll.
      Before, ctrl+scroll and shift+scroll scrolled pagewise. Now it’s only shift+scroll. Hence, I don’t plan to add an option, really…

      1. Thanks, I was not aware of shift, don’t remember seeing it in the manual too, I may just have forgotten. In that case, yes, I do agree with the change, I will need to adjust, but that’s it.

        Sorry If I ask this too early, but about the other point, what do you think about my reply to mous16 comment? Would that be a solution?

        Knowing where block end if very important for some less structured languages like PHP where the “}” can be hidden far away in HTML code. Debuging “artist code” is most of the time a terrible task. Having an overview of the structure is almost necessary because the code itself don’t look to have any. One thing I never liked about the rainbow was that it was not possible (or at least I never new how) to keep a block selected when the mouse was not over it. Scrolling long block was harder because of that.

        Visually knowing where block end is also useful for variable scope. In any language, but even more in functionals one (like lua or JS) the whole concept of member variable is manager in block depth. I always like to see the blocks for that. I am a very visual coder and I am probably not alone.

        I will try to come up with more use cases, if your not convince yet, just reply to this command and I will post more.

  3. Great, the rainbow wasn’t too much intuitive for me.

    Like Emmanuel, I also think that there should be a way to know where a block ends. What about placing ,on the scroll bar, an horizontal bar at the end of each block, like a closing parenthesis?
    To simplify the view, they could be colorized, so each arrow collapse the code to the parenthesis with the same color.


    1. I don’t think scrollbar is a good idea, if the block is too small, then it will be visible on the same page, so there is no way to add it in the scroll bar. But you make me think, it would be great if the folding widget associated with the position of the cursor (not the mouse, the text cursor) would always be highlighted (not in full selection color, something more gentle, let say 30% opacity?).

      -It would replace the rainbow for its most useful use case
      -It is less hard on the eye than differencing between 10 different tint
      -It does not require to much processing time as we don’t have to select or event be aware of the content, kate already know the line number, so the widget associated with a line is probably trivial
      -It is more keyboard friendly and automated than having to use the mouse to highlight blocks

      I think it is a nice compromise. Adding keyboard shortcut to increase and decrease depth level could be added later to complete the old feature set in a much more keyboard friendly and consistent way. I was not so happy when I say the original commit about removing the rainbow, but I think, done well, this simpler, more consistent approach would eventually lead to a better kate.

  4. Dominik,
    Kate doesn’t compile here – the build breaks in folding-related code.

    /home/adys/src/kde/kate/part/document/katedocument.cpp: In member function ‘virtual void KateDocument::readParameterizedSessionConfig(const KConfigGroup&, long unsigned int)’:
    /home/adys/src/kde/kate/part/document/katedocument.cpp:1633:27: error: ‘SkipFolding’ is not a member of ‘KTextEditor::ParameterizedSessionConfigInterface’
    /home/adys/src/kde/kate/part/document/katedocument.cpp: In member function ‘virtual void KateDocument::writeParameterizedSessionConfig(KConfigGroup&, long unsigned int)’:
    /home/adys/src/kde/kate/part/document/katedocument.cpp:1688:27: error: ‘SkipFolding’ is not a member of ‘KTextEditor::ParameterizedSessionConfigInterface’
    make[2]: *** [part/CMakeFiles/katepartinterfaces.dir/document/katedocument.o] Error 1
    make[1]: *** [part/CMakeFiles/katepartinterfaces.dir/all] Error 2

  5. I clearly prefere the old behavior. I agree, the color doesn’t fit in the theme very nice. Considering that the color stays the same if you change the overall kde color theme, there might be space for improvements.

    So please let the old behavior stay as an alternative option.

      1. For me, the flat design looks _much_ better than the new “3D” one, too. Looks kind of cheap. I can’t test the new kate atm, but it appears to me from the screenshot that the current block (as well as all other blocks) is not marked until you hover the bar. Wouldn’t it be better to mark the current block, without the need to move your mouse?

  6. I know this is an old thread, but this change just recently percolated to my machine. I liked the old rainbow colors… is there any way to get them back? Please?


  7. Code folding in Kate does not work properly for me on a Ubuntu 12.04 system. The folding markers highlight the text that will be folded when hovered over. This is usually from and including the marker down a few lines. I can fold text but afterwards hovering over the unfold marker does not just highlight the line it is on as expected. It highlights from the unfold marker up to the next marker which doesnt seem to be normal behaviour at all. I cant unfold the hidden text. Instead clicking on the unfold marker folds the highlighted part from the unfold marker to the marker above.

    Help would be greatly appreciated. Mightnt be back for a few days though.


Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top