Go support

[Phil Norman]

Hi.

In recent days I've finally got my arse into gear, and have added Go support for syntax highlighting and indentation. I'm probably the only person who writes Go and uses Evergreen, but never mind.

I was wondering though - how many people actually use this editor? I hope I'm not the only one. But the users group is veeeery quiet.

Note: even if I am the only person using it, I'm not switching.

Cheers,

Phil

[Martin Dorey]

I wasn't the only person using Evergreen here... before we just laid off 80% of my team.  Perhaps I am now.  I pushed a change just the other day, in response to someone else here being tripped by the symlink handling, but he's now gone.  I doubt most of our users here knew about the group, although I do see two ex BlueArgh subscribers apart from Elliott.

I don't write Go.

Welcome back!

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.
Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

[Elliott Hughes]

i still use Evergreen every day, but it long ago reached the "good
enough" point for me. sure, there are a few things that could be
better. (plus i'm too busy to even get through all my work work!)

for me, clang-format integration would probably be the biggest
possible improvement. but it wouldn't change my life enough that i'm
likely to find time for it. (and i can always add to the "Tools" menu
before i go even further.)

--
Elliott Hughes - http://www.jessies.org/~enh/

[Phil Norman]

Yep, for me it's also "good enough" not to bother trying to do too much work on it. The crappy Go support was causing me some pain though, hence the recent changes.

That said, I wouldn't mind making a few other fixes here and there, for as long as my interest bout lasts.

Are there any other things that particularly annoy? I think possibly my greatest annoyance is the fact that if I pipe a text buffer through an eternal command, I always end up looking at the top of the file. I have a hotkey set up to pipe the whole file (or buffer) through an external formatter (which delegates to gofmt or clang-format according to file type), but it has this annoying jump-to-top effect. I was thinking of maybe doing something simple, like if the scope is the whole file, positioning the caret at (old line number / old line count) * new line count. That should at least have you mostly looking at the same part of the file. Sound sensible?

If anyone wants to give me their top 5 irritations, I could have a think. Maybe if there are a few we all share, they'd be worth tackling.

BTW, I have a little script which wraps clang-format, and does sneaky stuff with braces, such that if you select a portion inside a function, it maintains the indentation of the first line and doesn't assume that's the start of the file and it should push it all to the left. If anyone's interested, I can paste it in.

Cheers,

Phil

>> email to evergreen-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to evergreen-users@googlegroups.com.

>> Visit this group at https://groups.google.com/group/evergreen-users.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "evergreen-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to evergreen-users+unsubscribe@googlegroups.com.
> To post to this group, send email to evergreen-users@googlegroups.com.

> Visit this group at https://groups.google.com/group/evergreen-users.
> For more options, visit https://groups.google.com/d/optout.

--
Elliott Hughes - http://www.jessies.org/~enh/

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-users+unsubscribe@googlegroups.com.
To post to this group, send email to evergreen-users@googlegroups.com.

[Martin Dorey]

The indenter is my only gripe. It's not perfect on my code but a pain on some other styles.  I wish I could more easily turn it off.  I thought I was even running with a reversion of one of the "more recent" (2012-01-17) changes, but git tells me that I must have lost them in the move from svn.  I'll dig it out...

Got to love automatically shared mobile/desktop Drafts.

Index: src/e/ptextarea/PCFamilyIndenter.java

===================================================================

--- src/e/ptextarea/PCFamilyIndenter.java (revision 6966)

+++ src/e/ptextarea/PCFamilyIndenter.java (working copy)

@@ -23,12 +23,12 @@

     public ArrayList<Preference> getPreferences() {

         ArrayList<Preference> result = super.getPreferences();

         result.add(new Preference(ALIGN_FUNCTION_ARGS, Boolean.TRUE, "Align args in multi-line function calls"));

-        result.add(new Preference(NAMESPACE_INDENT, "", "Indent after C++ 'namespace xx {' lines"));

+        result.add(new Preference(NAMESPACE_INDENT, "    ", "Indent after C++ 'namespace xx {' lines"));

         result.add(new Preference(BRACE_INDENT, "    ", "Indent after an open curly brace"));

         result.add(new Preference(SQUARE_BRACKET_INDENT, "    ", "Indent after an open square bracket"));

         result.add(new Preference(PARENTHESIS_INDENT, "    ", "Indent after round brackets (also expression continuation)"));

-        result.add(new Preference(SWITCH_LABEL_OUTDENT, "", "Outdent for 'case' and 'default' switch labels"));

-        result.add(new Preference(ACCESS_SPECIFIER_OUTDENT, " ", "Outdent for access specifiers"));

+        result.add(new Preference(SWITCH_LABEL_OUTDENT, "    ", "Outdent for 'case' and 'default' switch labels"));

+        result.add(new Preference(ACCESS_SPECIFIER_OUTDENT, "    ", "Outdent for access specifiers"));

         return result;

     }

I'll apply that to my git area, see if I'm less unhappy.

I see I had another suite of changes for deferring open an errors window until the tool has something to say... and deferring the banner on our scm tools until there's something else to say.  The idea being that sometimes it would never have anything to say and that way we end up with fewer spurious windows.  I think that worked OK.  I'll move that over if that chimes with anyone else.