@chris26 @riveravaldez @kazhnuz @shmerl

I think I have distracted the subject of this thread.

Is it appropriate to create a new thread to discuss about combined search?

or someone who draws better than me in English, created here vote for that?

@juansantiago : This proposal covers advanced search, so you can add your implementation details if you want.

I think they are related, since following tags and actual search all perform queries based on similar logic. So implementation will likely have a lot of shared parts.

@chris26 : I think such syntax is prone to more problems than more clearly defined #(...) I.e. it has higher ambiguity during analysis. In case of using regular tags you'll still have to parse the whole text (either until the end, or until the next # used in the next tag) before figuring out whether the previous one was a regular tag or you still didn't reach the end of the multiword tag. It's rather demanding and introduces complexity.

On the other hand, if you see #( you know right away that you are starting a multiword tag. It means less ambiguity and simpler parser.

@shmerl : Your vote makes sense to me. This is also a concern of mine. But I wonder. Are we talking about the parser being outright prone to failure? Or are we talking about the amount of work required for a CPU?

If the latter, how much difference are we really talking about?

@chris26 : Any difference can reduce performance. In this case it also affects readability at editing time. When you edit the post, you can easily see beginning ( and ending ). And when you use exactly the same symbol for beginning and end of the tag - you'll have hard time visually catching them. I would have liked your proposal more if at least you used different symbols for beginning and end (that won't solve the issue of parser complexity, but at least would improve readability at editing time).

Alternatively you can simply use another symbol altogether to reduce ambiguity (i.e. less common one than round brackets which are often used in text).

Example:

{multi word tag}

Then there won't be a need to put # in the beginning at all and it would be readable and easy to parse.

curly-brackets sounds like a plan to me. Leave the functionality of #, and add {} tags.

I want to second Shmerls argument here. #bla bla# might cause unwanted ambiguities and makes the code bad to test. I'd also prefer something like #(..) #"..." #[...] or #{...}.

My suggestion is to use something that fits more with the Markdown syntax that Diaspora already uses. Since we have name, why not just use [Tag Link] by itself. It is fairly easily to parse. Though, if you want the hash, I'd be more inclined to say [#Tag Phrase].

Can someone explain why we even need tags with whitespace?

"5. Hashtags themselves don’t allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations like “#areallylonghashtagyoucanbreakyoureyeson”, or people trying to come up with workarounds (like using underscore or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them)."

I think that the proliferation of alternate syntaxes is a great problem.

I think that the proliferation of alternate syntaxes is a great problem.

That's the point - making one standard in diaspora* will reduce usage of other makeshift methods like described. And will increase readability.

@jonnehass :

Can someone explain why we even need tags with whitespace?

It's explained quite clearly in problem #5 in the proposal. So let me repeat it:

Hashtags themselves don’t allow whitespace in them which is caused by the syntax restrictions and results in awkward unreadable notations like “#areallylonghashtagyoucanbreakyoureyeson”, or people trying to come up with workarounds (like using underscore or camel notation, which proliferates incompatible tags and defeats the purpose of searching by them).

I think caml casing is common enough and works fine, I'd even consider removing support for _ in tags. We already downcase for comparison, so #fooBar, #FooBar and #foobar are all the same tag.

Can someone explain why we even need tags with whitespace?

No idea. I gues it's because of a misunderstanding about the usage of hashtags, but it's only suppositions.

I think this all needs a serious police investigation. please call the experts ! :D

What if dashes were automatically deleted? That way, for example, #GNU-Linux and #GNULinux would all end up at #gnulinux. Also, if the curly-bracket thing is implemented, #{GNU Linux} would also go to the same place.

Right off, I can tell this would be inconvenient/insensitive when talking about someone with a hyphenated name. I'm just spit-balling.

All of this is not a question why we need multiword hashtags. They are already used and in all kind of incompatible ways. This proposal is about making a clean syntax rather than leaving this chaotic.

#FooBar is bad (not readable for long tags). #foo_bar or #foo-bar are not compatible with #FooBar and etc. But all of them are used to convey the same idea. All of those problems are described in #5. Whitespace in tags would provide one standard way and would make them actually human readable (which is important!).

I’d even consider removing support for _ in tags.

I think it would be good to allow users to create tags containing underscores and hyphens, but to 'strip' these characters from the linked tag, so a search for #foobar also returns results from #foo_bar and #foo-bar.

I see no benefit in coding for tags with spaces in - that seems to me something which is just going to create all sorts of situations in which users create tags when they don't mean to, and so on.

I'd prefer not to strip anything from tags and use them as the user intended. Otherwise it will only increase the confusion.

I thought this topic was somehow related to the approach to realize groups through a hashtag. That would seem like a nice idea to me although I would prefer to realize groups with something else.

But concerning readability: we might get a conflict between readability and writability. Let's imagine the hashtags #merrychristmas and #{merry christmas}. Which one would you use in your postings AND which one are you expecting that other users are using in their postings? In fact I expect curly brackets to be so hard to type that only the super-hardcore-nerds would ever use them.

What if dashes were automatically deleted? That way, for example, #GNU-Linux and #GNULinux would all end up at #gnulinux. Also, if the curly-bracket thing is implemented, #{GNU Linux} would also go to the same place.

To me, implement another syntax is just visual pollution. For long tags, you just have camel case. I have never understood the nedd for doing sentences with hashtags...

They are juste used to sort posts in subject, not write these posts.

super-hardcore-nerds

No, something only super-hardcore-nerds would use would be merry christmas.

And it's not like we're dealing with tildas ( ~ ) or pipes ( | ) or anything. I think curly-brackets are fairly understandable. Maybe straight brackets ( [ ] ) would would be preferred, just so you don't have to hit the Shift key quite so much.

I don't think it's any more difficult than embedding an image with Markdown.

To me, implement another syntax is just visual pollution. For long tags, you just have camel case.

Which is unreadable - I simply never waste my time on breaking eyes on such hahstags.

Our syntax, with spaces, is not just another syntax, it's our natural syntax. The maddening proliferation of four different syntaxes (CamelCase, hyphens, no space, hashtags on each word) only results from our initial inability to emulate it. Obviously the natural syntax will catch on everywhere if only we give it a chance and D* is a good place to start.

#"natural syntax"

But concerning readability: we might get a conflict between readability and writability.

Let's clarify. The result can be displayed in the post without brackets at all. Brackets are needed only for editing the post.

Which is unreadable - I simply never waste my time on breaking eyes on such hahstags.

Tags are not intended to write sentences, yet. I really don't see the need for writing super-long hashes. #ConsiderImWritingMyPostsEntirelyWithTags #IsItUsefull ?

Really, tags are just a way to mark a post as concerning a subject. Nothing else....

Sentences are off-topic. We're dealing with terms.

"Terms are words and compound words that in specific contexts are given specific meanings—these may deviate from the meanings the same words have in other contexts and in everyday language."

Really, tags are just a way to mark a post as concerning a subject. Nothing else….

Yet they are often used inside posts. So we can either ignore current lack of readability, or we can improve it. I'm for the second option.

Yet they are often used inside posts.

Which is pretty stupid to me. But that's just my feeling...

So we can either ignore current lack of readability, or we can improve it. I’m for the second option.

I'm for the first. I'm really sick tired of the proliferation of the hashtags which reduces the readability and are really useless in other usage than categorize a post.

New thread with the proposal to improve search https://www.loomio.org/d/fKts1wR2/improvement-diaspora-search-engine

I'd say trying to stop ambiguity by introducing yet another syntax is a fallacy, especially if it requires distinct syntax and thus knowledge. All this leads to is that we would not only have #foobar, #foo_bar and #foo-bar (I actually wouldn't mind disallowing _ and - in tags altogether), but also #"foo bar". Given enough users all versions will always exist.

I’d say trying to stop ambiguity by introducing yet another syntax is a fallacy

No. Having no standard way of making multiword hashtags and expecting all users to follow one way is a fallacy. Having a standard at least gives users an option to follow it, and others to point to it if they see it not being followed. Having no standard means what it means - legitimate chaos. No one will force users to follow it anyway, we are talking about giving a standard option.

You can write hashtags backwards for all I care. But if there is no standard option, you can't even start talking to anyone about following one notation.

So why not support all the different ways that are currently possible?

I think it would be good to allow users to create tags containing underscores and hyphens, but to ‘strip’ these characters from the linked tag, so a search for #foobar also returns results from #foo_bar and #foo-bar. (@goob)

Fuzzy tags would make diaspora's way of treating hashtags modern and easy to use.

Oh, and I don't think #hashtags should contain whitespace because if they do, the other words look like links or just like they're lost and lonely. I mean, look at this one.

#going out with the dog

"#Going out with the dog", with the traditional distinctive colour, is as readable as any other hyperlink.

Using a known syntax, natural syntax, does not require prior knowledge.

The absurd proliferation of syntax variants is a result of not having a natural syntax in the first place and I applaud Schmerl's proposal.

Re : stripping tags of hyphens, underscore, etc : You can easily retrieve variants from the #"natural syntax" tag (#NaturalSyntax, #natural-syntax, etc.) but it is close to impossible to reliably automate the generation of other variants from #naturalsyntax. It's a dead end.

In contrast, the implementation of #"natural syntax" on D* could involve the semi-automatic generation of common variants : #NaturalSyntax and #natural-syntax.

“#Going out with the dog”, with the traditional distinctive colour, is as readable as any other hyperlink.

There's at least one reason why hyperlinks do not contain white spaces. White space are traditionnaly the separator bitween two distinctive elements. A link with a white space in the middle isn't one link. It is one link and something else.

This will be a mess to process.

And I still don't understand the need for making sentences with hashtags...

@Perig Gouanvic : I think you agreed in the last vote not to the original proposal, but to the specific implementation proposed by Chris.

There’s at least one reason why hyperlinks do not contain white spaces.

What are you talking about? There are tons of hyperlinks with whitespace. Even on Diaspora stream page itself. For example "Post to diaspora*" (bookmarklet).

You can easily retrieve variants from the #“natural syntax” tag (#NaturalSyntax, #natural-syntax, etc.) but it is close to impossible to reliably automate the generation of other variants from #naturalsyntax. It’s a dead end.

I think you misunderstood. Of course it's hard to try to query all variants of a hashtag, a search for #cat would need to check for #c-at, #ca-t, #cAt, #cA-t_ and so on. Therefore stripping functionality should occur at the same time as the lowercase modification, when the post is written. Correct me if I'm wrong.

After this one ends, I can create a vote on proposal matching the original idea of #(...) or similar method.

What are you talking about? There are tons of hyperlinks with whitespace. Even on Diaspora stream page itself. For example “Post to diaspora*” (bookmarklet).

I speak about hyperlinks. Not overlying text.

Hyperlinks perfectly allow whitespace.

Example:

<a href="something">that's a hyperlink with whitespace!</a>.

How is it any different than:

#(that's a tag with whitespace which will look like hyperlink in the text)

https://www.loomio.org/d/R3zBvnfc/improving-and-expanding-hashtags-usability

No whitespaces...

My point is it is useless and it is deploying useless efforts to solve an inexistant problem. For the third time : I don't see the need for making sentences with hashes.

See my example above. Hyperlinks can have whitespace, period. It was always used in hypertext. What you posted is an URL, not a hyperlink. I see no point in redefining what a hyperlink is.

inexistant problem

The problem was explained clearly (proliferation of incompatible tags and no standard with natural way of using simple notation). It's not non existent, you just don't consider it a problem while others do.

I like the point that the curly brackets would only be at the writing stage. If they came in at the reading stage too (i.e. appeared in posts) that would just be another syntax.

@alexb : The original proposal is relevant to the writing stage. I.e. result will look like #multiword tag. Curly brackets can also translate into the same result when page is displayed.

Ah -- I thought you had moved to supporting curly brackets. I think they're better than rounded brackets because we do use rounded brackets so much more in everyday sentences. It seems to me easier for the post-writer to quickly scan the post they've written before pressing "post" and differentiate asides (round brackets) from multiword hashtags (curly brackets).

Apart from that difference, I meant to approve what you had written rather than suggest a revision. As your example in your last post shows (to me, anyway), the reader knows from the hyperlink highlighting that the set of words are all one link, and knows from the hash that the link is a tag. It's a simple and natural way of displaying it.

I'm OK with using curly brackets preceding them with the hash:

#{some tag} which will look like #some tag in the actual displayed post.

I agree that it's cleaner than using round brackets which are more common for regular punctuation.

See my example above. Hyperlinks can have whitespace, period.

Ok ! If you put a period, I just have to deal with it.
Best argument ever !

@shmerl

I’d prefer not to strip anything from tags and use them as the user intended. Otherwise it will only increase the confusion.

The tag can still be displayed with any underscores/hyphens inserted by the user, but it would be parsed as if no hyphens/underscores were present. This would (I think) improve tag searches, while still allowing users to present tags as they like.

After this one ends, I can create a vote on proposal matching the original idea of #(…) or similar method.

Wouldn't it be a good idea first to have a vote on allowing tags containing spaces (yes/no), before having many different votes on different syntaxes for tags containing spaces? There would only be any point in making proposals for different syntaxes if there is a vote of yes for having tags containing spaces.

One other consideration is how tags created in Diaspora will function in other services to which posts containing tags are pushed. For instance, Twitter.

Now I don't think we should be constrained in what we do by the limits or expectations of other social services, but where Diaspora offers cross-connectivity, we should make sure any changes built in will allow that connectivity to continue functioning properly.

@goob : There can be several ways to deal with pushing to other more limited services. Either you skip multiword tags, or you convert them to some other notation as a fallback (snake, camel, whatever). As you said, diaspora* shouldn't be constrained just because other such services have less functionality.

Wouldn’t it be a good idea first to have a vote on allowing tags containing spaces (yes/no) before having many different votes on different syntaxes for tags containing spaces?

Spaces are an example of syntax for multiword tags and an important part of the proposal to improve usability. If you want I can make a vote on spaces first.

@augier : Sorry, but if you want to use different definition, it will only confuse the discussion. Please stick to the accepted terms so others would understand what you really mean.

Please extend the proposal for a longer time, core features like this should not be voted in 3 day proposals. At least two weeks would give more people time to give an opinion. Personally I'm strongly against this, but just saying that this is not the way votes should happen, with only 3 day possibility to vote, imho.

Please extend the proposal for a longer time, core features like this should not be voted in 3 day proposals.

The vote is not about the core feature proposal, it's about a particular syntax idea from @chris26 . Please read the details of the vote.

I'll make next vote about the original proposal longer.

On twitter people use capitalisation to denote words which seems to work pretty well.

I don't think Diaspora should worry about what Twitter does exactly. We should evaluate what is useful for Diaspora itself. And different incompatible ways of using multiword tags are a problem, no matter what Twitter does.

It's important to note that the hashtag came about organically on Twitter as a way users came up with themselves to denote the subject of their post. It was only after this became an obvious trend that Twitter made it part of their site's function. So coming up with a new syntax for hashtags on Diaspora would conflict with natural usage, so seems rather foolish.

So @shmerl when I reference Twitter I'm talking about how people naturally use the medium, not how Twitter has decided to make something function.

So coming up with a new syntax for hashtags on Diaspora would conflict with natural usage, so seems rather foolish.

You miss the point. Users already use multiword tags, whether you consider it foolish or not. This proposal is about giving a standard option to do it, instead of what is happening now. There is no "natural" uniform usage now. There are many natural incompatible usages.

Those who disagree, please state your reasons in order to come up with better alternatives.

Better alternative = no multi-word tags

Better alternative = no multi-word tags

That's impossible, you can't force it on users. They are already actively used and will be used - we'll have to live with that. This discussion is about improving usability, and not about forbidding or not multiword tags.

Simple example - #OccupyWallStreet - that's a multiword tag which expresses some single entity. You can't do the same thing with splitting it into three tags. There are many valid reasons why multiword tags can be used.

This discussion is about improving usability, and not about forbidding or not multiword tags.

So why a proposal then if you don't take disagreement as an opinion?

So why a proposal then if you don’t take disagreement as an opinion?

Let me clarify. This is not a proposal to "allow / not allow" multiword tags. Such proposal is senseless. Multiword tags are already used and will be used. Forbidding them makes even less sense. How are possibly going to forbid them and what for?

This proposal is about improving usability of such tags (with providing a standard syntax of defining them).

So please state your opinion on the proposal, not on the idea of "allow or not multiword tags".

So, this proposal is about improving usability of such tags (with providing a standard syntax of defining them).

The proposal clearly says "with whitespace". That is not something that can be done at the moment. So you are proposing multi-word tags that do not exist.

And my opinion is no. Confusing for non-geeks. Not used anywhere else. Try to please accept other peoples opinions.

The proposal clearly says “with whitespace”.

Yes, that's exactly the proposal on improving usability of multiword tags.

So you are proposing multi-word tags that do not exist.

Yes, that's a proposal to expand current tags syntax. Currently used multiword tags are used without whitespace which has several problems clearly described in the proposal itself.

Try to please accept other peoples opinions.

Before you said you want to forbid multiword tags altogether. That's not the same as no to whitespace. I just want to be clear that you mean the same thing.

Before you said you want to forbid multiword tags altogether.

Such a comedian, very funny.

Please stay on topic and stop trolling.

Since Jason got confused, multiword tags means tags with many words. Syntax can be different. If anyone missed that - they are already used. Not just in Diaspora, but in Twitter and any other place which uses tags. Examples were given above.

The reason to use them is quite straightforward - sometimes you need to use phrase as a tag, and one word isn't sufficient.

From disagree to strong block due to author acting hostile

Who was being hostile here? You started completely off-topic and unprofessional ad hominem attacks in the discussion when you said:

Such a comedian, very funny.

and when you were asked to stop trolling you call that hostile? Be responsible please. Derailing the discussion with personal attacks is what not helping any productive results.

Those who disagree, please state your reasons in order to come up with better alternatives.

Because it's a bad idea.

The proposal is based on the complaint that there are currently too many ways to enter a multi-word tag, but proposes yet another way to do it.

Better to change the parsing of tags so that, just as results containing both #mytag and #MyTag currently appear in a search for either of them, results for #my-tag and #my_tag would also appear (along with any variants of these) in a search for any of those variants.

The proposal is based on the complaint that there are currently too many ways to enter a multi-word tag, but proposes yet another way to do it.

@goob : That's just part of the issue. Another part of the issue is poor readability of tags without whitespace, which for some reason most here simply dismiss as irrelevant. However it makes them simply noise which distracts from reading the post, ranging from small annoyance to making the whole thing highly unreadable.

For this reason for example I always avoid using tags in the middle of the post, and just make a list of them in the end. But a lot of people mix tags with the body of the post in my experience.

The hashtag is used in the same way everywhere, a hashtag is used in "camel" mode

I saw plenty of hashtags used with dashes or snake notation. While Goob's idea to drop them during search will help partially, readability of such tags displayed in the post will remain very poor.

Hashtags with whitespace may be useless to you but it's not to others. There's no sense in blocking something that really does have legitimate use just because you don't want it. You're not being asked to write the code, just if there's a legitimate reason it should not happen. So far, there are no legitimate concerns.

On a more technical mean : it will just be a pain in the ass to process. Algorithms to extract classic hashes extists. No one to extract hashes w/ whitespaces. So we'll have to code it. No way...

. Another part of the issue is poor readability of tags without whitespace

See Jonne's opinion : hashtags does not exist to be readable. They exist to agrgregate posts with subjects.

There’s no sense in blocking something that really does have legitimate use just because you don’t want it.

Not just that. I really don't care who want's it or not. I just strongly believe this will be harmful

Indeed, they are clearly not useless for everyone. So far concerns which were voiced were:

1. it's confusing.
2. tags aren't categories.
3. the proposal can't reduce proliferation of incompatible tags.

About #1 - I'm not sure it's any more confusing than using hyperlinks with whitespace which are used everywhere. People don't look confused about it.

#2 - I'm not sure really how it affects the usage if they are categories or not. Tags are used for search and anchoring certain posts together. And they are actively used for that purpose in phrases forms already (for example - "free software", "open source" etc.). So however we defined their theoretical idea, right now we are talking about practical usage which is already prevalent.

#3: Removing proliferation completely is impossible - users can always come up with incompatible ways - you can't hold user's hands about it. But what you can do is providing an easy to read standard option.

Algorithms to extract classic hashes extists. No one to extract hashes w/ whitespaces

What, you say that parser for #{...} is much more complex than parser for #xyz? It doesn't look to be more complex or resource hungry. The other proposal (from Chris) was indeed introducing more complexity because of that syntax specifics. But whitespace alone - doesn't.

hashtags does not exist to be readable.

That was answered already. What matters is how they are used in practice, not how we define them in theory. And practice contradicts that. I.e. unreadable tags are used all around in the middle of posts which implies that you have to read them.

So ignoring that and saying - "hey, they don't follow the definition, so who cares" doesn't really help anything.

Not just that. I really don’t care who want’s it or not. I just strongly believe this will be harmful

Can you elaborate please how it can be harmful?

I guess, we soon will need some regularities on when and who and how can someone block a voting, how long the voting-duration should be and that code-details shouldn't be part of the decision. I think, "we cannot reuse other's people's code" (see Augier's "So we’ll have to code it. No way…") is a bad argument to reject a proposal. See, we are working on Diaspora and want to change the world; it is obvious that we can't achieve that just by using code of other people.

Nevertheless it is my own opinion that this feature is not really necessary.

What, you say that parser for #{…} is much more complex than parser for #xyz?

I say that we do not do this job by ourselves currently. It is done by an external gem. So, yes, it is much more complex if we have to do this by ourselves...

And practice contradicts that. I.e. unreadable tags are used all around in the middle of posts which implies that you have to read them.

Seriously, how many posts do you read with very long tags ? In what does it block the message comprehension ? What I say is : hashtags should be next to the text body. Not in it, and obviously not it....

Can you elaborate please how it can be harmful?

It adds work, another confusing syntax, another way to write multi-word tags, meaning another possibility to not find all the posts related to this tag, another incompatibilty with other tools (FB, twitter, red matrix, etc...) other algorithmics problems to solve (how to display it, how to process it, how to add it in databases), etc, etc... And unfortunatly, it does not bring us devs...

Seriously, how many posts do you read with very long tags ? In what does it block the message comprehension

It happens not infrequently. It blocks it in a very simple way - more than often I just stop reading that post and move to the next one.

It adds work, another confusing syntax, another way to write multi-word tags, meaning another possibility to not find all the posts related to this tag, another incompatibilty with other tools

I think all of those concerns were already addressed above. Syntax isn't confusing (it's already widely used for hyperlinks) and anyway it's optional and no one is forced to use it. Search can be adjusted anyway to unify things, similar to what Goob proposed and export to other tools can be addressed on individual basis following their limitations (for example spaces can be stripped and so on). Another way to write which is standard is something that users can be directed to if they aren't aware. No standard way means you can't even suggest it properly.

another incompatibilty with other tools (FB, twitter, red matrix, etc…)

#"multi word hashtag" and #multi_word_hashtag can both be used with RedMatrix.

@rasmusfuhse

some regularities on when and who and how can someone block a voting,

A block is only a No vote, we voted on that early on when we started using Loomio. It doesn't block anything, we just calculate no+block votes against yes.

#OccupyWallStreet works fine without spaces.
I only see disadvantages for using something like #(Occupy Wall Street)
1. It's not easier to use
2. It's not intuitive
3. It breaks compatibility with sites that use normal hashtags
What's the upshot?
That said, I do think better searching/following/filtering options would help!

Or should we support using images/soundstreams etc as tags too? ;)

Actually yes. There was a proposal already to support audio and video tags. Simplicity which reduces usability is not a good thing at all.

You want us to vote down your proposal all over again? Ok then....
I think specifying a syntax for tags is unnecessary and not a good use of people's time.

I guess I just don’t understand why whitespace is such a big deal. If you’re worried about appealing to “non-technical” people, anything you come up with is going to be just as “technical” as using camelCase or hyphens or whatever. As I stated earlier, this is a non-issue with smart search algorithms, which is something you want to have anyway.

@Perig Gouanvic , what does this have to do with “evolution of the semantic web”? Could you expand on this a little more?

You want us to vote down your proposal all over again?

I'm not sure to whom you refer as "us", everyone votes here for oneself, unless you mean to represent some group of people? And it's the first time the vote is held on this proposal, so what do you refer as "again" to? The previous vote was on the limited idea of using to hashes for delimiting.

I guess I just don’t understand why whitespace is such a big deal.

Readability. The proposal actually describes what the problem is.

I see #hashtags as short classification of content with keywords. thus using more than one word seems "unintentional" to me.
Sure, the current parsing rules allow for #camelCase (and thus multiple words), but as a person with some experience in programming I would find it strange to complain about something like camel-case ;)

So I suppose it's still not possible to search for multiple hashtags? Seems like a very important feature to be searching for just the posts that you'd like to look for.

In the end the syntactical phrasing shouldn't matter too much. The key is that any user should be able to search for just what they want to find. Thus, there should be a nice "Advanced tag search" view or something so that one could just add:

Search for: #energy #technology #sustainableenergy (Info: this will look for all posts that have all specified tags)
Also include: #solarpower #windpower (Info: all posts with any tag specified here will be listed)
Exclude: #nuclear (Info: no posts with any of these tags will be listed)

This does not cover all cases but offers a reasonable amount of flexibility that a person would want in a search.

How in the end this will be translated shouldn't bother the user much. If still programming style searching should be possible then just enable it for those advanced users (e.g. "((#energy & #technology) | #solarpower | #windpower) & !(#nuclear)"... simply using basic bool operators.

The biggest problem I see around here is that a focus is missing: User-friendliness. Think of the person that has absolutely no idea about programming, or doesn't know what electricity is but still uses a computer. If those users can use your interfaces well, then you've found the correct ones.