Nick completion with tab key instead of/additional to @

[ghost]

Please make nick completion also work with tab key instead of selection by starting @.
Many other clients do work that way.

Examples:
typing "woj" results in "Wojtek: " in the input line.
typing "a" cycles through available nicks starting with "a" and might result in second nick with "a" like "Andrzej: "

At least in BeagleIM that would be helpful. I don't know if this is desireable for mobile clients such as SiskinIM, though...

[ghost]

Ups... should be filed under BeagleIM...

[eevvoor]

I agree. In MUCs it's kind of annoying to have the additional @ sign and people continuously try to teach to beagle-im-users that the @ is not necessary -- not knowing about the tab completion issue from the users client.

[mdosch]

I was pointed here because I was trying to teach a Beagle user too to not put the @ in front of my username as my clients won't notify me because my username is Martin not @Martin.
So important messages might be read delayed or not at all if it is a busy MUC and notifications do not work due to the arbitrary @.

[woj-tek]

I'd argue, that having explicit mention prefix makes sense and expresses definite intention.

Have you considered asking developers of your client adding support for notifying on mentions in both forms?

[mdosch]

I asked in xmpp:[email protected]?join and most don't like to prefix mentions with @. They said you might consider to do it the way converse.js does it: Writing an @ lets you cycle through the userlist to find the person you want to mention but the @ is removed in the outgoing mention.

[woj-tek]

Current situation is is not ideal and it seems that the best way forward would be to implement XEP-0372: References: Mentions and while we consider it there is no ETA.

[Neustradamus]

It works in MUC Room with Psi for example.

We type the first letter (or two or more), after tab key, the first username is detected, tab again, the second...

[woj-tek]

Great that it works in other applications. Though, it's never been specified so that's customary at best. Morover, it can lead to excessive notification when we namedrop someone without intention to rise attention.

[eevvoor]

I see your point @woj-tek. Unfortunately virtually all XMPP clients use mentioning without @. Thus it is a problem if beagle IM tries to push mentioning best practices. Is there a way to meet current usage?

[Ppjet6]

Current situation is is not ideal and it seems that the best way forward would be to implement XEP-0372: References: Mentions and while we consider it there is no ETA.

This is indeed what's been mentioned in jdev@ yesterday. This is to me the best decision that would allow not mixing input format and wire format.

Just to clarify for non-technical users:

This way, while a BeagleIM user types @ and then autocompletes nickname, the client itself (BeagleIM) would send on the wire some protocol magic without including @ in the text.

Receiving clients can then (reading the protocol magic) see that they have been mentioned, and display a @ (or no character, or any other character they fancy) alongside the mention. Clients that don't understand this protocol magic will just display the text as usual, nothing changes from what was before.

In any case, with or without the @, a receiving client needs to have its implementation changed if it wants to e.g., reduce noise when the user is just being named without the intention to rise attention (reusing @woj-tek's example).

[woj-tek]

Copy-paste from XSF muc:

@eevvoor we are not specifically against (where did you get that from) but we simply won't drop just like that because there are other factors at play;

most likely we will address it (0372?) but it will take some time. Besides, 0372 has it's own issue ("A begin attribute is used to mark the index in the body of the referring message of the first character (TODO: define character appropriately)", erm... :-) ) so it will take some time.

and in case of other clients it boils down to having issue with detecting @ + nick.

Regarding counting, @Ppjet6 mentioned XEP-0426: Character counting in message bodies though, given virtually non-existent adoption of xep-0372 won't help much.

[eevvoor]

opposed to virtually non-existent adoption of @ as user mentioning 😁

[woj-tek]

Well, it seems that except xmpp-ecosystem everyone is on board with @-mentions ;-)

It's simply quite convenient and intuitive to users.

[eevvoor]

Hm I somewhat disagree.

[woj-tek]

Let's see, from the top of my head I know that: github, twitter, mastodon, facebook, slack, whatsapp, MS teams, mattermost and telegram uses @ as mention.

The issue at hand is not about using @ as a mention indicator but rather how to transmit that.

[ghost]

Hmmm, for me it seems that implementing an XEP would be more work to do than just to add a little bit of code to have nick completion by pressing tab key. Also remember that using @ involves a little bit of finger acrobatics: you'll need to press the option key + "L" which I (at least) do with the right hand fingers (thumb on option key, index finger on "L", which is not a "good" practice, IMHO.
Using tab key for nick completion would be faster/better to type because most users would type one or two letters, in this example it would be: (middle finger left hand) "W", (ring finger right hand) "o", (ring finger left hand) "Tab" -> "Wojtek". At least that would be how I would type or use it. I think it is more a natural way to type instead of needing to use Option Key + "L" for "@".

Comparing web-based apps like Github or Facebook is not the same like comparing text-based apps like IRC or XMPP. Mastodon on the other hand uses the @ at the start for addressing the remote user, so it's a different thing as well. Otherwise you would need to type the complete JID instead of just the nick.

In the end, I do see the point of having @ to address people in the chat. It is quite common these days, coming from the bad habit of doing this first in some web forums, later in IRC (you got kicked for doing such a nonsense in some channels ;-)) and in other apps on mobile devices where often there is no Tab key at all on the virtual keyboard (or hidden in some special ways), whereas the @ is often quite prominent available on the screen in most cases.
But this was for BeagleIM, which is a desktop app, not SiskinIM, so the last argument with virtual keyboard doesn't count for Beagle.

I still believe adding an alternative to (not necessarily replacing) @ addressing and offer the user nick completion by using Tab key would benefit many users, is the easiest way to implement and makes many people in MUCs happy that otherwise might always tell the Beagle users that using "@" in front of their nick won't highlight their nick in their own clients. :-)

[hantu85]

@ingoj While I agree that dropping @ from nicknames would make non-Beagle users' life easier.

However, as it was mentioned by you, @ is commonly used on the web and on mobile platforms, so why you want to force people on desktop using native clients no to use @? They are already accustomed to from other platforms.

I do feel that this discussion is pointless as BeagleIM did not break any standard, only did not follow "best practice" which were not written anywhere.

The only real solution is switching to XEP-0372 that defines how XMPP clients and servers should mention someone within the room/channel/1-1 conversation.

However, I suppose that XEP-0372 would be problematic for anyone using OMEMO - mentions are not encrypted.

As for "use XEP-0426 for character counting", it would be great to just mention that in XEP-0372.

[Neustradamus]

In Psi, it works without "@".
If we test with "@", it does not work.

[woj-tek]

@Neustradamus have you considered submitting bug ('it does not work')/feature request to Psi developers though?

[Neustradamus]

It is only to inform you that it can work without "@".