Bookmarks being removed when using AStyle

[OnlineCop]

I tried Googling "bookmarks" for any C::B answers for this one, but I thought I'd send it here.

I set bookmarks through my code.  When I call the AStyle "Source code formatter" plugin, all the bookmarks are removed.

Is this a bug?  Or a "feature" by design?  I would understand that AStyle, being a separate plugin, may not be fully supported here, but I can't imagine why bookmarks should be removed whenever it re-styles code.

Is there a way to configure AStyle to leave bookmarks where they are, even if "not moving" the bookmarks means I'll have to go through and manually adjust everything myself?

[MortenMacFly]

I set bookmarks through my code.  When I call the AStyle "Source code formatter" plugin, all the bookmarks are removed.

I'd say this is not easily possible. AFAIK astyle get a "dump" of the source-code, re-formats it and returns it as a new "dump". It works just as the command-line astyle and doesn't know about bookmarks and stuff. So one would need to patch astyle to incorporate this additional functionality and I don't believe that this is a good way because it requires a lot changes and you would have to incorporate this again and again on new astyle upgrades.
With regards, Morten.

[tiwag]

i think the bookmark linenumbers could be easily stored in the .layout file
and were then accessible throughout several edit sessions.

when astyle changes the code, the bookmarks don't need to change too,
they could stay at the linenumbers where they were before.

[MortenMacFly]

when astyle changes the code, the bookmarks don't need to change too,
they could stay at the linenumbers where they were before.

But does that make sense? If astyle changes the code like e.g.:

Code

void my_method() {
  dostuff()
}

...into:

Code

void my_method()
{
  dostuff()
}

...then the line numbering changes. So the bookmarks are out of sync. In fact that happens 99% of the time I'd say. So why saving the bookmarks then? IMHO it's really better to remove them under that condition.

With regards,, Morten.

[tiwag]

when astyle changes the code, the bookmarks don't need to change too,
they could stay at the linenumbers where they were before.

But does that make sense? If astyle changes the code like e.g.:

it does not make any sense, if you have bookmarks and change the
astyle source code style completely e.g. from K&R style to ANSI, where
you get heavy source code modifications.

but in general it makes sense, even when the bookmarks don't change their linenumber with the astyle changes,
you have them "near" the original location in most cases (which is better than lost esp. when you are editing long files)
and normally you set your favourite astyle source code style and don't change it.

[OnlineCop]

I'm going with tiwag's argument:

I would find it far better to have 20 bookmarks that have to be manually moved when the code is modified either through AStyle or external programs, than to have all 20 completely disappear.

If my code is several hundred lines long (which is completely conceivable: the few exceptions would ever be "Hello World"-length programs), the bookmarks are "in the general area of" the different places they were set originally.  Sure, they'd move around a lot when changing styles.

For a "best of both worlds", why not allow the user to decide:

When the page is refreshed (through AStyle or otherwise):
( )Remove bookmarks
(x)Leave bookmarks in original position
( )Use 3rd-party plugin to try to keep bookmarks in generally the same place

Just an idea...

[MortenMacFly]

I take your votes, but I promise:
If we implement that we will get a lot people that will complain "Hey I've lost my bookmarks - they are shifted somehow.". If you can live with that - go on! ;-)
All I want to say is that both "solutions" are *not* an expected behaviour.
With regards, Morten.

[Ceniza]

There's a good workaround for it modifying the iterator to take care of bookmarks... but I'll need to find the functions to get and set bookmarks first.

I'll give it a try

[Ceniza]

OK, it seems I finally got it. It required a hacky check but it seems to be working pretty nice by now.

Why do I think the next request will be doing the same thing for breakpoints?

Let me know how it goes in the next release.

[MortenMacFly]

OK, it seems I finally got it. It required a hacky check but it seems to be working pretty nice by now.

Cooooool! (Compiling now...)