Shoutbox

How about calling it Toast Slices? Yummy...

For me the delimiter of %% is fine. Its different enough to be easy to remember, but also easy enough to not be too difficult

Looks good though. Hopefully they'll be a bit easier on you at university so you can focus some time on it. None of us want you working so hard you become ill!

Looks great, lookin' forward to next version!

quote:

---

Originally posted by Mnjul
1. What would you suggest for the name of this functionality? Split-message? Split-Toasts? Blahblahblah?

---

split-message seems ok ("toast slice" not, sorry Jeronimo, but that doesn't really tell what the function is about IMHO).

quote:

---

Originally posted by Mnjul
2. What would you suggest for the default delimiter that splits the messages?

---

Why using a double percent character? I guess the reason for that is because of possible usage in the message itself. What you could do in that case (and what I also always do in such cases) is making use of a "literal" character ("escape" character is maybe the proper name, dunno?).

In the rare case that people want to use the delimiter in the message, they should prefix it with "\". In that way, your plugin knows that the next character should be taken literally and not as a delimiter.

Doing this, makes 1 character delimiters possible, which is more convenient for the user IMHO (and the use of "\" in this way is actually something you'll find in other programs and languages).

The delimiter itself, dunno, but maybe something even less used than "%", yet easy typeable... hmmm... "^" or "#" maybe? dunno...

%% Sounds fine, kind of reminds me of spacing links with html so I and others could find it easy to remember. However hopper is extemtly popular and alot of non-advanced users will be using it. Maybe you could try something like this to make it eaiser for other users:

//
00
||
, (simple comma)
..
(place every new toast in brackets)

quote:

---

Originally posted by CookieRevised
split-message seems ok ("toast slice" not, sorry Jeronimo, but that doesn't really tell what the function is about IMHO).

---

I guess I'll use Split-Message then...
Toast Slice will be the codename of the function

As for things about the delimiter... what about this?
Whatever the user sets as the delimiter, if they need the delimiter to literally appear in their messages, they need to type it twice. Just like you need to type //nick in a conversation window for /nick to literally show. For example, if someone sets $ as the delimiter and he wants to show "I bought a new car today" "It cost me $40000" then he has to set "I bout a new car today$It cost me $$40000" as Hop message. This should be easier to remember...

As for the default delimiter, I currently have in mind one backslash \ - I guess many programming languages have escape sequences begining with it for a reason (though I don't know what reason it is )...

Anyone?

sounds good to me ...

or maybe make the default even "/" like in plus, then the analogy with Plus! and the double forward slash is totally complete? (and the user must already type / for commands to work, so....)

PS: Though double typing a delimiter to get the literal character has the disadvantage that you can not end the first part with the literal character. Because the last character of the first part and the delimiter form together a double character and thus will be interpreted as literal... You don't have that when you use an different literal "identifier"... But I can live with that

quote:

---

Originally posted by CookieRevised
PS: Though double typing a delimiter to get the literal character has the disadvantage that you can not end the first part with the literal character. Because the last character of the first part and the delimiter form together a double character and thus will be interpreted as literal... You don't have that when you use an different literal "identifier"... But I can live with that

---

Hmm...I get what you mean, Cookie... if someone types "Blahhhh///Blah", I wouldn't be able to know if he wants to show "Blahhhh/" "Blah" or "Blahhhh" "/Blah"...this is kinda trivial but I have to keep it from happening.

If I use one literal identifier such as \ in the previous example, "Blahhh/" "Blah" would be "Blahhh\//Blah" and "Blahhhh" "/Blah" would be "Blahhh/\/Blah"...

OK So the delimiter is / and the literal identifier is \, anyone?

---

Update: I am still not sure about it..what if a user wants the identifier to show in the end of one part? Like he wants to say "Oh gosh\" "Blah"? ..."Oh gosh\/Blah" will be parsed into "Oh gosh/Blah"...Oh wait..does that mean for the identifier to show literally, the user has to type it twice?

So now I have a delimiter, and a literal identifier...for the delimiter to show literally, it must be prefixed with the identifier...and for the identifier itself to show literally, it must be typed twice...quite troublesome, huh..any possible change?

Anyone with satisfactory answer for picky Mnjul? :<

quote:

---

Originally posted by Mnjul
So now I have a delimiter, and a literal identifier...for the delimiter to show literally, it must be prefixed with the identifier...and for the identifier itself to show literally, it must be typed twice...

---

indeed, because in that case the first \ is still seen as the 'literal identifier' and the second is seen as just another character which needs to be taken literally.

quote:

---

Originally posted by Mnjul
quite troublesome, huh

---

not really. You don't need to look at it as three different things or special cases, as they are in fact all the same.

The 'identifier' \ must be seen as an escape character, a character with a special function. As soon as it is encountered it is interpreted as a "command" and the function of the following character is determined by what that character is. (Which is indeed the function \ in other stuff too, eg in C style languages, think about \n, \t, etc...)

If the next character has a special meaning (in the parsing routine), that special meaning is interpreted, otherwise it just takes the next character literal, no matter what character it is.

For your plugin (in case you're going to implement it that is), this means it takes every character literally that comes after it, no matter what character, just that simple. The only special case would be the delimiter. (Unless, you also include \n which will be parsed as a linefeed and \t as a tab... maybe also a suggestion for even extra possebilities?)

To give some examples (and I'll use $ as delimiter just for better visualization of the examples though)

"Oh gosh"   "Blah"  => needs "Oh gosh$Blah" 

"Oh gosh$"   "Blah"  => needs "Oh gosh\$$Blah" 

"Oh gosh"   "$Blah"  => needs "Oh gosh$\$Blah"

"Oh \gosh"   "\Blah\"  => needs "Oh \\gosh$\\Blah\\" 
but the above is nothing special, it is just the same case like:
"Oh gosh"   "Blah"  => needs "\O\h\ \g\o\s\h$\B\l\a\h"

I use the same, without the delimiter of course, in the HolidayCounter Plugin for defining the shown text and to make a difference between tags and literall text: "(d) days ago I typed \(d)" will be parsed as "5 days ago I typed (d)" because "\(" is just seen as "(" literally and thus the rest of the text "d)" isn't a tag anymore which needs replacing.

---

Or instead of the delimiter being a single character, you also could make it into a 'special function' for the escape character itself of course (but then the user needs to type 2 characters in everyday use, but it would be consistent with the rest though). But I don't think you want to go that far, though it is nice and consistant with all the rest.... dunno. eg:

\d is parsed as the delimiter
\n is parsed as a linefeed
\t is parsed as a tab
\? (where ? is any other character) is parsed as taking ? literally

---

EDIT: In reference to MnJul's reply: all the above was meant as POV from the user though. It is how the user should look at it to understand how it works. That is, he doesn't need to know how it is programmed, but the above explains to him that there are no 'special cases', just 1 rule: "\" interprets anything as literal after it.

So, I didn't realize you could see it in two ways (POV from user and POV of programmer). Though both ways are almost the same in this case.

When I said "quite troublesome", I meant it was quite troublesome for my users (a little bit confusing for non-advanced users, like what Absorbation said)...it's not troublesome to code

quote:

---

Originally posted by CookieRevised
\d is parsed as the delimiter
\n is parsed as a linefeed
\t is parsed as a tab
\? (where ? is any other character) is parsed as taking ? literally

---

I wonder if you do need a tab-space or a newline in such a small notification window - but this is a good idea and I'll do it (for fear that there is geeeeeeeeek Hopper users, of course ). And!! \d being the delimiter sounds quite fine for me actually...

And all these being taken as the escape sequences I think there is no need to configure them in HCC

Anyway, thanks for your input, Cookie and others Now this is what I have in mind... I'll have \d for the delimiter, \n \t as linefeed and tab respectively and if the character following \ is nothing special I'll print the character (without the backslash).

Any comments?

---

What I want is everything to be easy and straightforward for my users - that is, they can do what they want to do with only reading the least documentation (or tooltip contents, whatever).
Hopper's users don't have the chance to "experiment" with it... If they wrongly run Hopper's command and get undesired results, they are stalled by AFP and have to wait for minutes before they can run another one.

The new version has been released

Glad I am able to make it before Chinese New Year (this Saturday is the Chiense New Year's Eve...)...

It's 5am and I shall call it a da...urm...dawn.