C++ support #1820
C++ support #1820
Conversation
| @@ -250,16 +303,22 @@ def code_insert_is_not_null(): | |||
| actions.auto_insert(" != NULL") | |||
|
|
|||
| def code_state_if(): | |||
| actions.insert("if () {\n}\n") | |||
| actions.key("up:2 left:3") | |||
| actions.insert("if (") | |||
There was a problem hiding this comment.
I'm not sure we documented this anywhere but on the community backlog sessions we had decided to just directly use snippets here.
There was a problem hiding this comment.
Admittedly, I didn't quite know what to do with these. They existed in the original C-support, and all I did was comment out the part that breaks if you use an editor that adds closing braces/parentheses. Personally, I stopped using the "state " commands. I'm totally fine with removing them.
| @@ -7,7 +8,7 @@ tag(): user.code_comment_line | |||
| tag(): user.code_comment_block_c_like | |||
| tag(): user.code_data_bool | |||
| tag(): user.code_data_null | |||
| tag(): user.code_functions | |||
| # tag(): user.code_functions | |||
There was a problem hiding this comment.
Could you explain why you have disabled this?
There was a problem hiding this comment.
That is a good question. I remember being upset that funky didn't have any means to sneak in a return type for the function you're defining. Started experimenting with a more specific funky command, but from the looks of it I never finished that...
[<user.c_qualifier_list>] <user.c_type> funky <user.text>:
qualifiers = c_qualifier_list or ""
insert("{qualifiers} {text}")
This has been alleviated for me by defining the function definition snippet to use the auto return type and simply using snip funky for everything. Maybe I should just reinstate that tab.
| state type deaf: insert("typedef ") | ||
| state type deaf struct: | ||
| insert("typedef struct") | ||
| insert("{\n\n}") | ||
| edit.up() | ||
| key('tab') | ||
| key('tab')preprocessor |
There was a problem hiding this comment.
| key('tab')preprocessor | |
| key('tab') |
There was a problem hiding this comment.
This may be that you have not finished migration yet but it makes sense for anything where you are doing text navigation in the midst of insertion to migrate to a snippet as this is less likely to fight with builtin editor commands.
There was a problem hiding this comment.
Apart from the accidental insert of the word "preprocessor", I didn't touch this at all. The use of typedef is discouraged in modern C++.
There was a problem hiding this comment.
Gotcha, OK. If you don't want to touch the existing C support that's fine; I had assumed that your accidental insertion meant you were trying to edit this code.
|
|
||
| # Declare variables or structs etc. | ||
| # Ex. * int myList | ||
| <user.c_variable> <phrase>: | ||
| (var|variable) <user.c_variable> <phrase>: |
There was a problem hiding this comment.
Would recommend keeping track of any places where you are changing existing functionality such it can be added to the breaking changes file.
There was a problem hiding this comment.
I thought about something like this, but then I basically completely overhauled the mode. I really wish I knew someone who was actually using the current C mode (or was confident that there actually isn't anyone).
There was a problem hiding this comment.
There are definitely people using the existing C mode. If you add things that are C++ only, no need to document that, only if you change them. This is the standard we use for community maintenance.
| mod.list("cpp_standard_types", desc="Types in the std namespace") | ||
| mod.list("cpp_namespace", desc="Commonly used namespaces") | ||
|
|
||
| ctx.lists["user.code_libraries"] = { |
There was a problem hiding this comment.
Potentially consider using Talon lists for these
I promised a long time ago that I would set out to unify support for C and C++. I've been tinkering with this for quite a while now, and I finally decided to wrap what I had up into a commit and put it here for inspection.
Isn't really cleaned up yet, but I would nevertheless welcome feedback. In particular, I myself do not actually program in C. So any feedback from someone who actually uses the current C support would be valuable.
While certainly far from perfect, it has absolutely improved my experience in writing C++ code.