vopash

I confirm this actually works and is really better than nothing.
However, I think fully functional GREP styling is a must in Publisher, since it doesn't require to search&replace after each text edit.

GREP Styles is the feature that would totally allow me to replace sluggish InDesign with Publisher. Would love to see it in the nearest updates!

+1 for GREP styles!
I totally agree with everyone here. Starting with setting a different font for a certain character that’s not included in your font, to adjusting character spacing for particular combinations, to doing the whole styling just when inserting text, to all those other scenarios, people here described. Configure once and forget about everything, the flaws in your font, all the styling …
I might throw a party when Serif implement this. This is my number one feature request for the Affinity apps!
AND: By no means least, just a big applause to Serif for what the Affinity apps are right now! I get more and more excited about them, the more I use them!

I confirm this actually works and is really better than nothing.
However, I think fully functional GREP styling is a must in Publisher, since it doesn't require to search&replace after each text edit.

GREP Styles is the feature that would totally allow me to replace sluggish InDesign with Publisher. Would love to see it in the nearest updates!

Hi Kat,
We should have a new video ready shortly for the Boolean improvements  The Apple text shortcuts are the ones referenced in this thread. 
Thanks
C

GREP Styles is the feature that would totally allow me to replace sluggish InDesign with Publisher. Would love to see it in the nearest updates!

I confirm this actually works and is really better than nothing.
However, I think fully functional GREP styling is a must in Publisher, since it doesn't require to search&replace after each text edit.

Try this; Make a Character Style called "Caution Hi-light" do a search for the word CAUTION: and for the replace field use the character style.

I agree there's a bug here. The bug is triggered by putting No break on the space after the words as well as the words themselves. With that attribute, it can't break before the next word. It does scan back to the start of the No break range, but stops one character too early so doesn't find the break after the previous space. I'll log this to be fixed in a future release.
 

In my former InDesign work, I used a “no break” character GREP-style on most texts so I don't have hanging words.Publisher doesn't have such features, however, it does have a regular search&replace allowing to apply a style to matched texts. “That's almost GREP-styling,” — I thought.
So, here's the bug.
Reproduction
I've made a “no break” character style. It adds a “no break” option to a text, nothing else; very simple. Then, I do a regex search equivalent to this (actually with a longer word list and in Russian) and apply this “no break” style to all matches: \<(?i:(a |the )) The rule finds whole words with the following (regular) space symbol. With short words like articles/prepositions/pronouns, it's a perfectly valid rule for finding spaces that shouldn't be broken.
What happens
When selected text has “no break” style, text goes outside the column:

What should happen instead
Text should stay in the column (I had to insert non-breaking spaces and clear styles):

Affinity Publisher 1.7.2 release version on latest macOS 10.14 release.

I can't even understand why you're asking. 
I believe it's self-evident that text should be constrained within its bounding box. Because if I needed the text to flow further to the right, I'd extend that bounding box in the first place. 
If there are non-breaking rules, the line should be broken either before or after, provided that the constraints are respected as the first priority. It's quite evident that this line can't be broken after non-breaking words (see the first screenshot), therefore it must be broken before (the second screenshot). When text flows outside of bounds,— when it is clearly possible to respect the bounds,— it is definitely a bug.

Absolutely a +1 for me.
GREP/Regex Styles is an absolute must. I create lots of nested list documents (bullets and numbering) with multiple styles per line, with various delimiters using brackets and stars. With InDesign I can paste in the text (with the numbers of tabs defining the nesting level) and my document is completely formatted. I have already bought several copies (VPP Store) of Publisher to play with, just to support you guys as a viable alternative to Adobe. I'd love to be able to start using it to completely replace InDesign and that the only feature that's stopping me.

I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 
correct

The request was not for regex-based Find/Replace, which already exists.
It was for defining Text Styles based on regular expressions, which would (I believe) allow you to say "whenever I create text content that matches <some regular expressions> assign <some style name> to it automatically".

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

Hi guys...I'm loving Publisher so far, and my first piece of feedback was top be exactly this same topic. I absolutely agree with @vopash about the inconsistency with modifier keys across all Mac apps, and how AMAZING it would be to not have the frustration with having to go against our built-in muscle memory when working with text in Publisher. I figured the reason the developers made it this way was to be consistent with Adobe products, which is also INCONSISTENT with every other Mac app. I seriously urge you not to follow their lead in the awful UI design choice, or at least provide an option to use the bad Adobe way or the smart Mac way.

I believe you mean by a character, or possibly by a glyph.  A symbol has a specific meaning in the Affinity applications which is unrelated to this topic.

tl;dr: Every macOS app “knows” to move cursor by word w/ Alt modifier. Publisher (Actually, any Affinity app) requires Cmd modifier, which is inconsistent. Actually, this problem applies to every of Affinity apps, but I won't spawn multiple topics. :)
Long version of the problem: Whenever I edit texts in text areas in Publisher, I get stuck with inconsistent modifiers. Publisher requires me to NOT use system hotkeys which work literally everywhere. Even worse, sometimes system modifiers work, and sometimes they do not.
E. g., in every app except Affinity apps including Publisher: 
Arrows ←→ move cursor by a symbol, Delete removes a symbol, Alt+arrows move cursor by a word, Alt+Delete removes a word, Cmd+arrows move cursor to the line beginning or end, Cmd+Delete removes anything up to line's beginning or end. This pattern is simple, elegant, memorizable and works everywhere.
In Publisher and any other Affinity app:
Alt+arrows alter a symbol's kerning, Alt+Delete deletes a word, Cmd+arrows move cursor by word, Cmd+Delete deletes a line. This inconsistency matters a lot to me, because I work with text in many different apps, and I can't adapt to Publisher's hotkeys at all. I believe it's the single most annoying issue for me. I understand that you won't change the default behavior because it copies (flawed) Adobe's hotkeys.
However, since many hotkeys in Publisher are now customizable, I ask for an option to assign my own hotkeys for kerning and support system-wide text navigation modifiers.