Recent

Author Topic: Code Map Suggestion  (Read 3718 times)

Pmknecht

  • Newbie
  • Posts: 2
Code Map Suggestion
« on: February 12, 2013, 08:46:56 pm »
Hi,

i just wonder if somebody will add this code http://www.delphigeist.com/2012/05/synminimap-or-sublime-text-minimap.html to the official lazarus ide? To get rid of the platform depency it is enough to replace the function which contains the StretchBlt with the regular canvas pendant.

Cheers

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5711
    • wiki
Re: Code Map Suggestion
« Reply #1 on: February 12, 2013, 10:21:59 pm »
I doubt that code for the original SynEdit will work in Lazarus.
The Lazarus SynEdit is a fork, and heavily modified

The idea of such an overview is somewhere on the todo....
« Last Edit: February 12, 2013, 10:23:44 pm by Martin_fr »

Pmknecht

  • Newbie
  • Posts: 2
Re: Code Map Suggestion
« Reply #2 on: February 13, 2013, 11:23:09 am »
Well thats correct, but it is not that big deal to change the code. I did this yesterday, and besides the fact that the editor hook solution i made is lousy it runs okay.
I'm aware that it needs a bit more work to run fluently - especially since the bitmap is quite memory consuming on large code, but it is a proof of concept: http://pastebin.com/yQAyL4Wc

I would really like to have such a function inside lazarus, because it is easier to memorize a code structure than to search all the time through code.

wp

  • Hero Member
  • *****
  • Posts: 6351
Re: Code Map Suggestion
« Reply #3 on: February 13, 2013, 12:58:33 pm »
A similar thing already exists in Lazarus, although at a less detailed level. It is the gray bar next to the scrollbar. You can identify the interface and implementation sections, as well as the location of breakpoints, text bookmarks and modified text. Maybe this is sufficient?
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

Ask

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 687
Re: Code Map Suggestion
« Reply #4 on: February 13, 2013, 05:19:51 pm »
I have always wondered about the usefulness of this feature.
It seems to me that if the shape of code is diverse enough to be distinguishable at such a small scale,
then the code is formatted inconsistently.

If I would take a single feature from Sublime, it would be "Goto anything". Procedure list is a good first step in this direction.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5711
    • wiki
Re: Code Map Suggestion
« Reply #5 on: February 13, 2013, 05:46:59 pm »
The shape of code does not need to be that diverse. For example divider lines can add to the info. Same if markup (like selection is visible.

You can actually get an idea, if you use the editors zoom (ctrl mouse wheel).

This however does not use a big bitmap and then a stretchdraw. This makes a difference, in that for example divider lines, stay a full pixel in height. Stretchdraw would anti-alias / fade them,  I guess.

Imho diructly painting with a small font, looks better than scalling. But it means the size can only be set in certain steps.

------------------------
Integrating the feature needs more than just painting.

Ideally it will (same as the overviewgutter) use a childwincontrol. So it get's it's own paint messages. That can reduce the paint over head a lot.

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

Also, I was unable to find a license on the code.

That said, if license is solved, it can be added as a component. It is always possible to later have both (stretchdraw and small font).

IDE integration can be looked at too....

------

Personally, I favour using the small font.

The current SynEdit & IDE has over 90% of the code in various places already. So it just needs to be put together.
« Last Edit: February 13, 2013, 06:04:35 pm by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5711
    • wiki
Re: Code Map Suggestion
« Reply #6 on: February 13, 2013, 06:47:46 pm »
Just noticed, this module does not apply any highlights.

Also it does not expand tabs. So the overview display will look different from the original.
Same applies to none monospaced fonts, which should be enforced to grid. And even within monospaced fonts, some chars may not stick to the grid. This sometimes happens with "full width" chars, that should be exactly 2 cells in the grid. But may in some fonts only be 1.5 cells
« Last Edit: February 13, 2013, 06:59:01 pm by Martin_fr »