Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bracket colors plugin #1221

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

asifamin13
Copy link

Bracketcolors plugin

  • Color { }, [ ], ( ) based on nesting order to make it easier to see the start/end bracket
  • Ignore brackets in non source code (strings, comments, doc strings, etc.)
  • Language agnostic

How it works

Allocates 3 indicators (starting at INDICATOR_IME - 3) to color each bracket pair as determined by SCI_BRACEMATCH. Ignore non source brackets as determined by highlighting_is_code_style

Dependencies

  • Geany 1.38
    • Need INDICATOR_IME from updated scintilla release
  • C++17
    • Mainly for std::map

Demo

image

@asifamin13 asifamin13 changed the title Bracket colors plugin Add bracket colors plugin Feb 3, 2023
@rdipardo
Copy link

rdipardo commented Feb 4, 2023

Perhaps the description and/or commit message should mention #1148?

@asifamin13
Copy link
Author

I updated the commit message with a reference to that issue. Raindow brackets sounds cool, I wish I knew of that issue before starting this

@elextr
Copy link
Member

elextr commented Feb 4, 2023

While "rainbow colours" sounds nice "Bracketcolors" is more descriptive, so a user looking for it is more likely to find it.

@eht16
Copy link
Member

eht16 commented Feb 5, 2023

Looks good! Thanks.

While "rainbow colours" sounds nice "Bracketcolors" is more descriptive, so a user looking for it is more likely to find it.

Full agree.
@asifamin13 maybe you could just mention "rainbow colors" in the README, that might already suffice that users can find it also with this name.

I did a quick code review without having a deeper look at the logic.
From a quick test, it works as advertised and I got many fancy brackets :).

A few comments @asifamin13:

BracketMap.cc: In member function 'void BracketMap::Show()':
BracketMap.cc:122:21: warning: loop variable 'it' creates a copy from type 'const std::pair<const int, std::tuple<int, int> >' [-Wrange-loop-construct]
  122 |     for (const auto it : mBracketMap) {
      |                     ^~
BracketMap.cc:122:21: note: use reference type to prevent copying
  122 |     for (const auto it : mBracketMap) {
      |                     ^~
      |                     &
bracketcolors.cc: In function 'gboolean utils_parse_color(const gchar*, GdkColor*)':
bracketcolors.cc:276:27: warning: 'gboolean gdk_color_parse(const gchar*, GdkColor*)' is deprecated: Use 'gdk_rgba_parse' instead [-Wdeprecated-declarations]
  276 |     return gdk_color_parse(spec, color);
      |            ~~~~~~~~~~~~~~~^~~~~~~~~~~~~
In file included from /usr/include/gtk-3.0/gdk/gdkcairo.h:26,
                 from /usr/include/gtk-3.0/gdk/gdk.h:33,
                 from /usr/include/gtk-3.0/gtk/gtk.h:30,
                 from /home/enrico/apps/include/geany/gtkcompat.h:30,
                 from /home/enrico/apps/include/geany/editor.h:27,
                 from /home/enrico/apps/include/geany/document.h:31,
                 from /home/enrico/apps/include/geany/build.h:26,
                 from /home/enrico/apps/include/geany/geanyplugin.h:36,
                 from bracketcolors.cc:40:
/usr/include/gtk-3.0/gdk/deprecated/gdkcolor.h:79:11: note: declared here
   79 | gboolean  gdk_color_parse     (const gchar    *spec,
      |           ^~~~~~~~~~~~~~~

Copy link
Member

@eht16 eht16 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and could you please add your plugin to the list in the top README?

bracketcolors/README Outdated Show resolved Hide resolved
bracketcolors/src/BracketMap.cc Outdated Show resolved Hide resolved
build/ax_cxx_compile_stdcxx_17.m4 Show resolved Hide resolved
bracketcolors/src/BracketMap.h Show resolved Hide resolved
@asifamin13
Copy link
Author

Looks good! Thanks.

While "rainbow colours" sounds nice "Bracketcolors" is more descriptive, so a user looking for it is more likely to find it.

Full agree. @asifamin13 maybe you could just mention "rainbow colors" in the README, that might already suffice that users can find it also with this name.

I did a quick code review without having a deeper look at the logic. From a quick test, it works as advertised and I got many fancy brackets :).

A few comments @asifamin13:

BracketMap.cc: In member function 'void BracketMap::Show()':
BracketMap.cc:122:21: warning: loop variable 'it' creates a copy from type 'const std::pair<const int, std::tuple<int, int> >' [-Wrange-loop-construct]
  122 |     for (const auto it : mBracketMap) {
      |                     ^~
BracketMap.cc:122:21: note: use reference type to prevent copying
  122 |     for (const auto it : mBracketMap) {
      |                     ^~
      |                     &
bracketcolors.cc: In function 'gboolean utils_parse_color(const gchar*, GdkColor*)':
bracketcolors.cc:276:27: warning: 'gboolean gdk_color_parse(const gchar*, GdkColor*)' is deprecated: Use 'gdk_rgba_parse' instead [-Wdeprecated-declarations]
  276 |     return gdk_color_parse(spec, color);
      |            ~~~~~~~~~~~~~~~^~~~~~~~~~~~~
In file included from /usr/include/gtk-3.0/gdk/gdkcairo.h:26,
                 from /usr/include/gtk-3.0/gdk/gdk.h:33,
                 from /usr/include/gtk-3.0/gtk/gtk.h:30,
                 from /home/enrico/apps/include/geany/gtkcompat.h:30,
                 from /home/enrico/apps/include/geany/editor.h:27,
                 from /home/enrico/apps/include/geany/document.h:31,
                 from /home/enrico/apps/include/geany/build.h:26,
                 from /home/enrico/apps/include/geany/geanyplugin.h:36,
                 from bracketcolors.cc:40:
/usr/include/gtk-3.0/gdk/deprecated/gdkcolor.h:79:11: note: declared here
   79 | gboolean  gdk_color_parse     (const gchar    *spec,
      |           ^~~~~~~~~~~~~~~

Thanks for the feedback!

  • The deprecated gdk* warning are ok. I removed the unused debugging code that was causing the others.
  • I added the bracketcolors entry to geany-plugins.nsi.
  • I confirmed my plugin behaves correctly when Geany colors brackets itself, like when brackets are missing

@asifamin13 asifamin13 closed this Feb 5, 2023
@asifamin13 asifamin13 reopened this Feb 5, 2023
@asifamin13
Copy link
Author

@eht16 I incorporated your suggested changes. I'm still learning Github, I apologize if I'm not navigating this pull request correctly 😅 (at my work, I'm used to Gitlab)

@asifamin13 asifamin13 requested a review from eht16 February 5, 2023 22:01
@eht16
Copy link
Member

eht16 commented Feb 12, 2023

@eht16 I incorporated your suggested changes. I'm still learning Github, I apologize if I'm not navigating this pull request correctly sweat_smile (at my work, I'm used to Gitlab)

No worries, it's fine.
Thanks for the changes. The PR looks good to me and I would merge it in a few days if nobody objects.

Comment on lines 299 to 305
static gchar char_at(ScintillaObject *sci, gint pos)
/*

----------------------------------------------------------------------------- */
{
return sci_get_char_at(sci, pos);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious: why the wrapper?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious: why the wrapper?

The documented return type of SCI_GETCHARAT is int, presumably for Unicode characters up to 32 bits in length. Squeezing that into an 8-bit(?) (g)char needs an explicit cast.

The (implied) point that just using the returned (g)int without a cast is worth considering. At the same time, the pos argument might be safer as the (platform independent) Sci_Position type. The API structures that can only index 32-bit positions are slated for eventual deprecation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documented return type of SCI_GETCHARAT is int, presumably for Unicode characters up to 32 bits in length.

No, that's probably either because int is "the" basic numerical type in C, or because of other historical reasons (and technically it is returned as a sptr_t). In practice, the returned value comes from Document::ChatAt() which returns a char. So if if want to be picky, it's actually a char stored into a sptr_t.

Squeezing that into an 8-bit(?) (g)char needs an explicit cast.

Well, yes, but… actually no: this does not actually wrap SCI_GETCHARAT, but Geany's own wrapper, sci_get_char_at() which has the exact same signature.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I was writing this, I was using the autoclose plugin as a template which has this wrapper as well. I suspect the authors of autoclose used the wrapper for convenience since it's used a lot, I don't really need it as bad to be honest.

@asifamin13 asifamin13 force-pushed the bracketcolors_v1 branch 2 times, most recently from c1f652e to 1e9a8b0 Compare March 10, 2023 23:58
@asifamin13 asifamin13 closed this Mar 11, 2023
@asifamin13 asifamin13 deleted the bracketcolors_v1 branch March 11, 2023 00:29
@elextr
Copy link
Member

elextr commented Mar 11, 2023

? why removed

@rdipardo
Copy link

? why removed

To get your attention, it seems.

@elextr
Copy link
Member

elextr commented Mar 12, 2023

Nah, it happens that people learning Git can stuff it up so bad its easier to start again, no problem.

But unfortunately that disconnects the discussion.

@b4n
Copy link
Member

b4n commented Mar 12, 2023

Instead of breaking the flow, just force-push your branch: git push -f origin bracketcolors_v1. You probably can even revive this one by simply reopening it, and if GitHub isn't smart enough, there's a bunch of tricks we could do to force it's hand.

@b4n
Copy link
Member

b4n commented Mar 12, 2023

Nah, it happens that people learning Git can stuff it up so bad its easier to start again, no problem.

Well, it usually is not easier, but people just don't know it 😅

@elextr
Copy link
Member

elextr commented Mar 13, 2023

Nah, it happens that people learning Git can stuff it up so bad its easier to start again, no problem.

Well, it usually is not easier, but people just don't know it 😅

Thats learning 😁

@asifamin13
Copy link
Author

asifamin13 commented Mar 14, 2023

Instead of breaking the flow, just force-push your branch: git push -f origin bracketcolors_v1. You probably can even revive this one by simply reopening it, and if GitHub isn't smart enough, there's a bunch of tricks we could do to force it's hand.

This is what I did, along with squashing several commits similar to this. I made the mistake of forgetting that I pressed the "sync with upstream" button (due to a warning I saw on the UI), and I ended up including (and taking ownership) of the upstream commits. Since the commits were all squashed together, I couldn't see a way to cleanly git revert. I then panicked and renamed that branch 'bracketcolors_v1_broken' and started over again with a new 'bracketcolors_v1' branch where I cherry picked the relevant commits I cared about from an older tree. But that ended up closing this pull request 💀

If any of yall can somehow reverse that mess, I owe you a beer.

@b4n
Copy link
Member

b4n commented Mar 14, 2023

If any of yall can somehow reverse that mess, I owe you a beer.

Challenge accepted, I'll see if I can convince GitHub quickly 🍺
Otherwise don't worry, it's not the end of the world

@b4n
Copy link
Member

b4n commented Mar 14, 2023

@asifamin13 actually I can't do it because I don't have permission to push to your branch.

If you want to try it out, I would think you'd have to do this:

  1. Close Add bracket colors plugin #1241 (GitHub doesn't like 2 PRs referring to the same branch)
  2. Recover this PR with git push -f asifamin13 1e9a8b0c32d15c27ba448e689545c0bc5c9b97aa:bracketcolors_v1 (assuming the remote to your own fork is asifamin13)
  3. Reopen this PR
  4. Re-add your latest changes: git push -f asifamin13 bracketcolors_v1.

Do not pull in between the steps, as step 2 is restoring your old state temporarily for GitHub's sake, and step 4 is trying to re-put your new changes there.

But again, if you're feeling out of your depth, there are two options:

  • allow maintainers to push to your PR
  • don't worry and accept that it's the cost of learning

@asifamin13
Copy link
Author

@b4n I added you as a collaborator, let me know if there are any problems.

I had some trouble with step 2

fatal: bad object 1e9a8b0c32d15c27ba448e689545c0bc5c9b97aa
fatal: the remote end hung up unexpectedly

I'm a bit out of my depth but I'm willing to learn. Where does that hash come from?

@b4n
Copy link
Member

b4n commented Mar 15, 2023

@b4n I added you as a collaborator, let me know if there are any problems.

Here you go, that PR is restored and should match what you had in #1241, 🍻
You can now push whatever you need (including force-pushing if necessary) and it should properly update this PR.

I had some trouble with step 2

fatal: bad object 1e9a8b0c32d15c27ba448e689545c0bc5c9b97aa
fatal: the remote end hung up unexpectedly

I'm a bit out of my depth but I'm willing to learn. Where does that hash come from?

1e9a8b0 was the commit this PR was at (as seen in the commits history before I force-pushed, and as you can see in the force-push notification above). The idea was to restore the branch to the state it had when this PR was closed so GitHub sees it as matching this PR, and accept re-opening this PR. If you didn't have that hash anymore, it means that Git's garbage collection got rid of it on your end (as it was an old commit not referenced by anything anymore); you could have gotten it back by fetching it from GitHub (as I did myself, git fetch asifamin13 1e9a8b0c32d15c27ba448e689545c0bc5c9b97aa).

@asifamin13
Copy link
Author

@b4n you are a life saver, your next beer is on me 🍻

I didn't realize git had garbage collection, I'll be sure to git fetch next time

This PR is back on track now 😄

@asifamin13
Copy link
Author

Fixed a bug to address a case when nested brackets weren't getting their color updated when their parent gets updated

@rdipardo
Copy link

rdipardo commented Apr 7, 2023

@asifamin13,

Fixed a bug to address a case when nested brackets weren't getting their color updated when their parent gets updated

Looks like a good improvement.

In the future, though, I would concentrate on just getting a minimal working version merged, then touch it up later in small, traceable iterations. To paraphrase the famous saying of Valéry, a pull request is never finished; it's abandoned.

@elextr
Copy link
Member

elextr commented Apr 7, 2023

To paraphrase the famous saying of Valéry, a pull request is never finished; it's abandoned.

Wise(ish) words, and its corollary, 'Every time a PR changes "somebody" has to re-check it and re-test it, and eventually "somebody" gets bored' :-)

@asifamin13
Copy link
Author

In the future, though, I would concentrate on just getting a minimal working version merged, then touch it up later in small, traceable iterations. To paraphrase the famous saying of Valéry, a pull request is never finished; it's abandoned.

Understood. What it currently on this branch is the "minimal working version". There is one more feature I want to add (user defined colors via preferences menu/config file). I'm working on this now, hopefully to be finished this week. I'll keep that on a different commit

Wise(ish) words, and its corollary, 'Every time a PR changes "somebody" has to re-check it and re-test it, and eventually "somebody" gets bored' :-)

I'm fine being that "somebody" haha I've had fun writing this plugin.

Do new plugin PRs getting pulled in on the next geany-plugins release?

@asifamin13
Copy link
Author

I added support for loading/saving settings via a GKeyFile

@asifamin13
Copy link
Author

I've been daily driving this plugin for several months now. I think it's stable enough to be merged.

The latest CI build failure seems to be from misconfigured runners.

@elextr
Copy link
Member

elextr commented May 20, 2023

The CI was awaiting a manual approval to run, approved, lets see.

Ideally needs someone who isn't the author to test it, nothing personal, but we all know how badly we test our own software :-)

@asifamin13
Copy link
Author

Hmmm, the other CI builds seem to work without a problem. For some reason this one isn't getting picked up:

This request was automatically failed because there were no enabled runners online to process the request for more than 1 days.

Ideally needs someone who isn't the author to test it, nothing personal, but we all know how badly we test our own software :-)

haha I understand. I'm always open to feedback if yall want to give it a try 😜

@eht16
Copy link
Member

eht16 commented Jun 10, 2023

Hmmm, the other CI builds seem to work without a problem. For some reason this one isn't getting picked up:

This request was automatically failed because there were no enabled runners online to process the request for more than 1 days.

Maybe this is related to the deprecated Ubuntu 18.04 build configuration in the workflow. Could you try to rebase your branch on current GIT master? The workflow/CI configuration has been changed a lot in the last weeks.
With a bit of luck, the CI will finally work then :).

asifamin13 and others added 2 commits July 5, 2023 11:18
Add bracketcolors plugin. Color {}, [], () based on nesting order

Closes geany#1148
* simple UI

* start hooking up signals

* mechanism to save settings from a conf file

* save load settings for defaults button

* less globals

* better config color name

* hook up colors

* glib types

* use colors from plugin config

* update colors when settings change

* reorganze, try to avoid giant files

* update document colors when they switch

* update headers

* fix bug when some brackets werent getting added to bracket map

* fix bug that was deleting newly inserted brackets

* std::map insert doesnt overwrite, use insert_or_assign

* handle when removing a bracket completes another

* handle invalid color specs in config file

* avoid static initialization fiasco

* if there are problems loading config, use defaults

* cleanup headers

* mark GUI labels as translatable

---------

Co-authored-by: Asif Amin <amin@arlut.utexas.edu>
@asifamin13
Copy link
Author

@eht16 I did the rebase, verified it compiles/works as expected on my rhel 8 workstation. Shall we give the CI another shot?

@eht16
Copy link
Member

eht16 commented Jul 9, 2023

@eht16 I did the rebase, verified it compiles/works as expected on my rhel 8 workstation. Shall we give the CI another shot?

The CI is fine.
Though you added quite some new code in the last commit which should be reviewed.

Btw, what is the "#5" referring to you mentioned in the commit message?

@asifamin13
Copy link
Author

It's from the pull request on my fork.

I'd appreciate any feedback, I added some GUI elements to specify custom colors on the plugin preferences page.

@asifamin13
Copy link
Author

Any chance this could make it into geany-plugins v2.0? 👀

@eht16
Copy link
Member

eht16 commented Oct 15, 2023

I'm afraid it's too late since the translation string freeze already happened. But we should finally review and merge it after 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants