Re: rcirc multiline nick adding

Re: rcirc multiline nick adding

[Ryan Yeske]

   Sorry. To be specific:

   the diff works for *my* usage with rcirc - and it is vital for that
   use case. But I use rcirc in quite a restricted way (mostly not
   general irc but for IM systems like jabber via a gateway).

   A couple of suggestions have been made about how I can generalize the
   fix and I'm exploring them.

Nic, you do know that you can do one-to-one chat in rcirc via bitlbee
by opening a query window instead of prefixing the message with the
users nick in the control channel, right?  In that case, multiline
posts to another user works as expected.

Ryan

-- 
http://www.yeske.ca

Re: rcirc multiline nick adding

[Richard Stallman]

Do you conclude that no change is claled for in rcirc.el now?

Re: rcirc multiline nick adding

[Ryan Yeske]

   Do you conclude that no change is claled for in rcirc.el now?

For the upcoming release, I suggest no change.

Re: rcirc multiline nick adding

[Nic James Ferrier]

Ryan Yeske <rcyeske@gmail.com> writes:

>    Do you conclude that no change is claled for in rcirc.el now?
>
> For the upcoming release, I suggest no change.

So do I. I was not intending to affect the release.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: rcirc multiline nick adding

[Richard Stallman]

    For the upcoming release, I suggest no change.

Ok, we won't change it.

rcirc multiline nick adding

[Nic James Ferrier]

I was having a problem with multiline not sending proper multiline
messages with bitlbee. This diff fixes it for me... not sure if
anybody else ever had the same problem.


--- /home/nferrier/rcirc.el~	2007-03-06 10:56:01.000000000 +0000
+++ /home/nferrier/rcirc.el	2007-04-18 13:50:05.000000000 +0100
@@ -1011,6 +1011,12 @@
   "Send the text in buffer back to parent buffer."
   (interactive)
   (assert rcirc-parent-buffer)
+  ;; Is there a nick at the start of the multiline buffer? if so add it to all the lines
+  (goto-char (point-min))
+  (if (looking-at "^[^ :]+: ")
+      (let ((nick (match-string 0)))
+        (while (re-search-forward "\n" nil t)
+          (replace-match (concat "\n" nick)))))
   (untabify (point-min) (point-max))
   (let ((text (buffer-substring (point-min) (point-max)))
         (buffer (current-buffer))


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: rcirc multiline nick adding

[Miles Bader]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:
> +  ;; Is there a nick at the start of the multiline buffer? if so add it to all the lines
> +  (goto-char (point-min))
> +  (if (looking-at "^[^ :]+: ")
> +      (let ((nick (match-string 0)))
> +        (while (re-search-forward "\n" nil t)
> +          (replace-match (concat "\n" nick)))))

This seems dangerous; what if it's not a nick?  It seems quite likely to
have annoying results...

-Miles

-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: rcirc multiline nick adding

[Nic James Ferrier]

Miles Bader <miles@gnu.org> writes:

> Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:
>> +  ;; Is there a nick at the start of the multiline buffer? if so add it to all the lines
>> +  (goto-char (point-min))
>> +  (if (looking-at "^[^ :]+: ")
>> +      (let ((nick (match-string 0)))
>> +        (while (re-search-forward "\n" nil t)
>> +          (replace-match (concat "\n" nick)))))
>
> This seems dangerous; what if it's not a nick?  It seems quite likely to
> have annoying results...

Well... with me it always is a nick. And it's vital that it be put
in.

Sending multilines through bitlebee without it is tricky.


Not sure there's another way to tell it if is a nick or not which is
partly why I pasted it here; maybe someone will have an idea.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: rcirc multiline nick adding

[Björn Lindström]

Nic James Ferrier <nferrier@tapsellferrier.co.uk>:

> Miles Bader <miles@gnu.org> writes:
>
>> Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:
>>> +  ;; Is there a nick at the start of the multiline buffer? if so add it to all the lines
>>> +  (goto-char (point-min))
>>> +  (if (looking-at "^[^ :]+: ")
>>> +      (let ((nick (match-string 0)))
>>> +        (while (re-search-forward "\n" nil t)
>>> +          (replace-match (concat "\n" nick)))))
>>
>> This seems dangerous; what if it's not a nick?  It seems quite likely to
>> have annoying results...
>
> Well... with me it always is a nick. And it's vital that it be put
> in.
>
> Sending multilines through bitlebee without it is tricky.
>
> Not sure there's another way to tell it if is a nick or not which is
> partly why I pasted it here; maybe someone will have an idea.

How about instead of doing this automagically, make this a text
editing command for multiline mode?

I.e. pressing C-c something inserts a nick followed by colon on each line.

Re: rcirc multiline nick adding

[Nic James Ferrier]

bkhl@elektrubadur.se (=?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=) writes:

> How about instead of doing this automagically, make this a text
> editing command for multiline mode?
>
> I.e. pressing C-c something inserts a nick followed by colon on each
> line.

Ooo! Or C-u C-c C-c?


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: rcirc multiline nick adding

[Miles Bader]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:
>> This seems dangerous; what if it's not a nick?  It seems quite likely to
>> have annoying results...
>
> Well... with me it always is a nick. And it's vital that it be put in.
>
> Sending multilines through bitlebee without it is tricky.

I don't really know the right terminology, but in rcirc there seem to be
two sorts of conversation buffers -- "private" buffers, where your
output always goes to a specific person, and "shared" buffers where you
use "user:" as a prefix to send to "user".

In the latter ("shared") buffers, it might make sense to do something
special with word-colon prefixes -- using an invalid username already
seems to get an error, at least using bitlbee -- but it doesn't really
in "private" conversation buffers, where such syntax doesn't seem to be
treated specially (though for whatever reason, nick completion still
works!).

I probably have some of the details wrong, so please correct me, but it
seems like a feature such as you propose would need to be active only in
"shared" conversation buffers.

Thanks,

-Miles

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: rcirc multiline nick adding

[Richard Stallman]

    I was having a problem with multiline not sending proper multiline
    messages with bitlbee. This diff fixes it for me... not sure if
    anybody else ever had the same problem.

Would someone please DTRT with this, then ack?

Re: rcirc multiline nick adding

[Nic James Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     I was having a problem with multiline not sending proper multiline
>     messages with bitlbee. This diff fixes it for me... not sure if
>     anybody else ever had the same problem.
>
> Would someone please DTRT with this, then ack?

I posted it to see if some better method could be suggested... it
doesn't work on it's own.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: rcirc multiline nick adding

[Richard Stallman]

    >     I was having a problem with multiline not sending proper multiline
    >     messages with bitlbee. This diff fixes it for me... not sure if
    >     anybody else ever had the same problem.
    >
    > Would someone please DTRT with this, then ack?

    I posted it to see if some better method could be suggested... it
    doesn't work on it's own.

First you said that diff fixes it.
Then you said it does not work on its own.
Which one is it?

Re: rcirc multiline nick adding

[Nic James Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     >     I was having a problem with multiline not sending proper multiline
>     >     messages with bitlbee. This diff fixes it for me... not sure if
>     >     anybody else ever had the same problem.
>     >
>     > Would someone please DTRT with this, then ack?
>
>     I posted it to see if some better method could be suggested... it
>     doesn't work on it's own.
>
> First you said that diff fixes it.
> Then you said it does not work on its own.
> Which one is it?

Sorry. To be specific:

the diff works for *my* usage with rcirc - and it is vital for that
use case. But I use rcirc in quite a restricted way (mostly not
general irc but for IM systems like jabber via a gateway).

A couple of suggestions have been made about how I can generalize the
fix and I'm exploring them.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk