Fix Espectro Mac keymap and add new layout option

[upinthecloudz]

Description

Logic in the process_record_user() function had a default to false, which prevented any keycodes NOT defined in this function from being processed as presses. Switching the changed line to return true allowed standard key presses to be acted upon normally.

Types of changes

• Core
• Bugfix
• New Feature
• Enhancement/Optimization
• Keyboard (addition or update)
• Keymap/Layout/Userspace (addition or update)
• Documentation

Issues Fixed or Closed by this PR

N/A

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document. (https://docs.qmk.fm/#/contributing)
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[noroadsleft]

Looks good to me. 👍

[drashna]

@noroadsleft ?

[noroadsleft]

Not sure what the significance of joined_right is. To me it doesn't mean anything.

@upinthecloudz could maybe answer this question better than I could.

I'd also prefer if it used the base32hex notation, consistent with the other macros, which would be:

#define LAYOUT_split_bs_joined_right( \
  K00, K01, K02, K03, K04, K60, K61, K62, K63, K05, K06, K07, K08, K72, K09,    K0A, K0B, K0C, K7C, \
  K10, K11, K12, K13, K14, K64, K65, K66, K67, K15, K16, K17, K18, K70, K71,    K19, K1A, K1B, K1C, \
  K20,    K21, K22, K23, K24, K68, K69, K6A, K6B, K25, K26, K27, K28,   K73,    K29, K2A, K2B, K2C, \
  K30,     K31, K32, K33, K34, K6C, K75, K76, K77, K35, K36, K37,       K38,    K39, K3A, K3B,      \
  K40,       K42, K43, K44, K78, K79, K7A, K7B, K45, K46, K47,     K48, K74,    K49, K4A, K4B, K4C, \
  K50,  K51,  K52,                 K59,                  K55, K57, K58, K53, K54,    K5A, K5B       \
) { \
  { K00,  K01,    K02,  K03,  K04,  K05,  K06,    K07,  K08,  K09,  K0A,  K0B,  K0C   }, \
  { K10,  K11,    K12,  K13,  K14,  K15,  K16,    K17,  K18,  K19,  K1A,  K1B,  K1C   }, \
  { K20,  K21,    K22,  K23,  K24,  K25,  K26,    K27,  K28,  K29,  K2A,  K2B,  K2C   }, \
  { K30,  K31,    K32,  K33,  K34,  K35,  K36,    K37,  K38,  K39,  K3A,  K3B,  KC_NO }, \
  { K40,  KC_NO,  K42,  K43,  K44,  K45,  K46,    K47,  K48,  K49,  K4A,  K4B,  K4C   }, \
  { K50,  K51,    K52,  K53,  K54,  K55,  KC_NO,  K57,  K58,  K59,  K5A,  K5B,  KC_NO }, \
  { K60,  K61,    K62,  K63,  K64,  K65,  K66,    K67,  K68,  K69,  K6A,  K6B,  K6C   }, \
  { K71,  K71,    K72,  K73,  K74,  K75,  K76,    K77,  K78,  K79,  K7A,  K7B,  K7C   }  \
}

[upinthecloudz]

There is an option for 3x 1u mods to right of spacebar before the arrows, or 2x1.5u mods. I figured since a key is 'split' when two are used in the space of 1, maybe they could be 'joined' when 2 are in the space of 3, but I don't mind changing it if there's a better way to term it.

I updated my branch with a layout that uses the base32hex and properly splits the backspace (instead of duplicating it to both keys with the K71 repeated in layout), and removed the superfluous return true line from the keymap.

[noroadsleft]

I think maybe 2r_mods or something similar (for two right-hand mods) might be better than joined_right. The problem is we don't really have a standard notation for this difference.

At the risk of having too many cooks, @mechmerlin what do you think?

[mechmerlin]

Thanks