Menu
▾
▴
erc-help — Archive of problems, bugs, features, news
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(46) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(6) |
Apr
(2) |
May
(25) |
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
(7) |
Nov
|
Dec
(18) |
| 2003 |
Jan
(8) |
Feb
(1) |
Mar
(2) |
Apr
(4) |
May
(14) |
Jun
(32) |
Jul
(15) |
Aug
(23) |
Sep
(23) |
Oct
(22) |
Nov
(27) |
Dec
(24) |
| 2004 |
Jan
(18) |
Feb
(38) |
Mar
(32) |
Apr
(18) |
May
(70) |
Jun
(1) |
Jul
(21) |
Aug
(19) |
Sep
(32) |
Oct
(11) |
Nov
(11) |
Dec
(19) |
| 2005 |
Jan
(48) |
Feb
(13) |
Mar
(19) |
Apr
(25) |
May
(4) |
Jun
(23) |
Jul
(8) |
Aug
(13) |
Sep
(12) |
Oct
(17) |
Nov
(4) |
Dec
(5) |
| 2006 |
Jan
(31) |
Feb
(30) |
Mar
(28) |
Apr
(11) |
May
(21) |
Jun
(7) |
Jul
(12) |
Aug
(5) |
Sep
(7) |
Oct
(24) |
Nov
(2) |
Dec
|
|
From: Alex S. <al...@em...> - 2005-01-09 01:34:01
|
Thank you! :) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fifth law: OOO Never accept more work than you can handle in one night of hacking. Date: Sun, 09 Jan 2005 02:33:52 +0100 In-Reply-To: <87e...@tu...> (Michael Olson's message of "Sat, 08 Jan 2005 17:39:26 -0500") Message-ID: <878...@co...> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
|
From: Jorgen S. <fo...@fo...> - 2005-01-09 00:58:54
|
Michael Olson <mw...@me...> writes: > http://sourceforge.net/project/showfiles.php?group_id=30118 You rock, thanks a lot! delYsid, when do you plan to upload that to the debian archives? Greetings, -- Jorgen -- ((email . "fo...@fo...") (www . "http://www.forcix.cx/") (gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet")) |
|
From: Michael O. <mw...@me...> - 2005-01-08 22:39:46
|
http://sourceforge.net/project/showfiles.php?group_id=3D30118 =2D-=20 Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: anim=C3=A9, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Edward O'C. <te...@oc...> - 2005-01-08 21:02:19
|
>>>>> Michael Olson <mw...@me...> writes: > A release will happen later today. I heard that hober has an XEmacs > compatibility patch of some sort for erc-track.el, so I'm waiting > until that goes in before releasing erc 5.0. I've committed this. Ted -- Edward O'Connor te...@oc... Ense petit placidam sub libertate quietem. |
|
From: Michael O. <mw...@me...> - 2005-01-08 09:12:50
|
I've completed all the copyright-related stuff in `debian/copyright' and the source file headers. A release will happen later today. I heard that hober has an XEmacs compatibility patch of some sort for erc-track.el, so I'm waiting until that goes in before releasing erc 5.0. If there are any other release-critical patches, feel free to install them and add the proper entry to `NEWS' (if relevant). =2D-=20 Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: anim=C3=A9, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Lawrence M. <we...@gm...> - 2005-01-06 21:36:38
|
Jorgen Schaefer wrote: > ** Some modules have been moved to erc-goodies.el > o The functions erc-add-scroll-to-bottom, erc-make-read-only, > erc-send-distinguish-noncommands, erc-interpret-controls, > erc-unmores, erc-smiley, and erc-occur have been moved to > erc-goodies.el, and have mostly been translated to the modules > scrolltobottom, readonly, noncommands, irccontrols, smiley and > unmorse. Thanks. I've now committed a preliminary NEWS, can people expand on it as they see fit? Unless it's ok. I've also added instructions in HACKING mentioning that if we introduce user visible changes, we should add them to NEWS. Lawrence -- Lawrence Mitchell <we...@gm...> |
|
From: Jorgen S. <fo...@fo...> - 2005-01-06 17:58:12
|
Lawrence Mitchell <we...@gm...> writes:
> * Changes since ERC 4.0
** Some modules have been moved to erc-goodies.el
o The functions erc-add-scroll-to-bottom, erc-make-read-only,
erc-send-distinguish-noncommands, erc-interpret-controls,
erc-unmores, erc-smiley, and erc-occur have been moved to
erc-goodies.el, and have mostly been translated to the modules
scrolltobottom, readonly, noncommands, irccontrols, smiley and
unmorse.
Greetings,
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: Lawrence M. <we...@gm...> - 2005-01-06 16:17:18
|
Michael Olson wrote:
> I'm planning on putting together a release of erc on Friday the 6th.
> If there are any major changes that still need to be completed, please
> let me know.
> Do we have a policy on what copyrights to list in `debian/copyright'?
> If not, I guess I'll add everyone who is listed in `AUTHORS'.
Hi there, here's a possible NEWS file, can people look at it and
add comments, corrections, additions?
* Changes since ERC 4.0
** Channel members are now stored as a hash-table.
`erc-server-users' and `erc-channel-users' are now hash-tables, rather
than alists. This significantly increases performance, especially in
large channels. Each channel member is stored as an `erc-server-user'
struct, with additional information about the channels they are on
stored in an `erc-channel-user' struct. Code using old alist-style
channel members needs to be updated to work with hash-tables.
This new code also removes the need for erc-members.el, which has been
removed.
** The way ERC deals with input from the server has changed.
All server response code is now in a new file, erc-backend.el. There
should be no real user visible changes. There are, however, a few
major changes for implementors, and module writers:
o The PARSED response that all handlers get called with is
no longer a vector, but an `erc-response' struct.
This means LESS MAGIC NUMBERS in the ERC source code, but a few
changes in how you get at parsed responses.
The sender is accessed via `erc-response.sender'.
The command is accessed via `erc-response.command'.
The arguments to the command (everything after the command and
before the colon) are accessed via `erc-response.command-args'.
This is a /list/ of arguments in the order they appear in the
unparsed response.
The contents of the response is accessed via
`erc-response.contents'.
Should, for some reason, you want to do something with the
/unparsed/ response, you can get it via `erc-response.unparsed'.
o The `erc-server-hook-list' mechanism is gone.
All server response handlers should be defined with
`define-erc-response-handler'. This defines functions and
corresponding hook variables.
The mapping of server commands to hook variables is no longer
done via `erc-event-to-hook', but through an #'equal hashtable,
`erc-server-responses'. In order to find a hook you do:
(erc-get-hook command)
See the docstring of `define-erc-response-handler' for more
information.
o ALL hook variables have been renamed.
In accordance with recommendations in the Emacs Lisp manual,
the hook variables are no longer called `erc-server-FOO-hook',
but rather `erc-server-FOO-functions'. This is to indicate
that the functions they call take arguments.
All the modules in ERC have been updated to reflect this change,
but external module authors should beware.
** ERC has a new way of displaying nicknames in a channel.
The new file erc-nicklist.el defines a new command `erc-nicklist'
which pops up a small Emacs window showing the nicknames of all
members of the current channel. The implementation is not complete
and is rather proof-of-concept for now. The result is something a bit
like erc-speedbar, but not quite as invasive, and doesn't require use
of a new frame.
--
Lawrence Mitchell <we...@gm...>
|
|
From: Michael O. <mw...@me...> - 2005-01-06 14:08:21
|
I'm planning on putting together a release of erc on Friday the 6th. If there are any major changes that still need to be completed, please let me know. Do we have a policy on what copyrights to list in `debian/copyright'? If not, I guess I'll add everyone who is listed in `AUTHORS'. =2D-=20 Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: anim=C3=A9, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Michael O. <mw...@gn...> - 2005-01-05 05:41:14
|
The files that fit the "ChangeLog.yyyy" form are the ChangeLog's of past years. `ChangeLog' is for the current year. Please update the `ChangeLog' file manually whenever changes are made. `HACKING' has been updated to this effect. =2D-=20 Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: anim=C3=A9, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Michael O. <mw...@me...> - 2005-01-05 05:29:22
|
I guess I've become the release manager for erc. Some of the authors have expressed their desire for a version 5 erc release. I made a new file called `FOR-RELEASE' that will contain a listing of these tasks. Please feel free to add to this file, especially the Stability section. =2D-=20 Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: anim=C3=A9, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: disumu <ds...@mu...> - 2005-01-02 15:52:55
|
A happy New Year to all, In CVS revisions 1.2 - 1.5 of erc-goodies.el there is a bug in `erc-controls-highlight' which gets emacs stuck in a loop if the \C-g control character is in a message. This occurs when the `irccontrols' module is enabled and `erc-beep-p' is set to nil (the variable's default setting). If you're using the latest CVS version of ERC, I highly recommend you update to the newest revision of erc-goodies.el (1.6 as of now) even you don't have irccontrols enabled in `erc-modules'. -- disumu |
|
From: Francis L. <fr...@wo...> - 2005-01-01 02:41:36
|
I have checked into CVS some changes that support stripping all IRC color and highlighting codes from text inserted into ERC buffers. To enable this feature, assign the symbol 'remove to erc-interpret-controls-p, which now has this docstring: *If non-nil, ERC displays IRC colors and other highlighting effects (such as bold and underlined text). One non-nil value is special: if this is set to the symbol 'remove, ERC removes all IRC colors and highlighting effects. When this variable is non-nil, it can cause Emacs to run slowly on systms lacking sufficient CPU speed. In chatty channels, or in an emergency (message flood) it can be turned off to save processing time. -- Francis Litterio fr...@wo... http://world.std.com/~franl/ GPG and PGP public keys available on keyservers. |
|
From: Jorgen S. <fo...@fo...> - 2004-12-25 02:06:34
|
Hi there.
I just committed some moderately big changes to CVS that I maybe
should have proposed here first. They actually intermingled two
things, and it was helpful this way.
First of all, I cleaned up some smaller cruft, made things modes
as they should be, and kicked out a huge pile of garbage (the IRC
control char interpretation).
I did this while moving this stuff into a separate file from
erc.el, namely erc-goodies.el. It's require'd by default from
erc.el, so nothing should change for the user.
See the commit log entries for details.
Greetings,
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: Lawrence M. <we...@gm...> - 2004-12-24 22:25:30
|
Hi people,
(long time no anything, well yes, life has intervened)
Over the christmas period, I thought I'd try and do something I've
been vaguely pondering for a while, namely trying to make ERC's
display slightly cleaner. Before, however, I jump in at the deep end
(it always seems to end in disaster), I thought I run some ideas past
people. The way I see things working is as follows. Comments,
suggestions, flames? They're all welcome to greater or lesser
degrees :).
Anyway, here goes:
How to do display in ERC --- A modest proposal.
Currently, ERC works on callbacks of some kind. We send a command to
a server, and sit around waiting for a reply. When a rpely arrives,
we parse it and hand it off to some handler to deal with. Display is
always carried out through ERC-DISPLAY-MESSAGE, which is rather
opaque. Now, stuff we send is not passed through this whole
mechanism, note the way if we send some text using erc-cmd-SAY, we do
not see it displayed in the same way that others see it. Equally,
sending NOTICEs to the channel works in a different way.
Proposal:
All display should be carried out through the same function, if we get
information from a server, we construct a message in the same way we
do now, and display it as usual. If we /send/ a message, we construct
what it /would/ look like had it been sent remotely, and send it
through the exact same lots of handlers. This is easily done, see
ERC-CALL-HOOKS.
Protocol (something like this anyway):
erc-message [structure]
All displayed messages are an erc-message structure. This structure
contains:
string --- the string that should be displayed to the screen
buffers --- a list of buffers in which the message should be
displayed
process --- the process associated with this message
type --- what type of message this is (e.g. CTCP), this will affect
how the message will be formatted.
displayp --- flag indicating whether we should actually display this
message anywhere
erc-parse-server-response (string) [function]
=> erc-message
This function parses a raw server string and creates an ERC-MESSAGE
structure from it.
erc-display-message (erc-message) [function]
This function takes an ERC-MESSAGE (most probably from
ERC-PARSE-SERVER-RESPONSE) and displays it to the screen.
erc-construct-local-message (string) [function]
=> erc-message
This function parses an input that we send and constructs an
ERC-MESSAGE structure from it. This can't be the same as
ERC-PARSE-SERVER-RESPONSE, because the format of commands that we send
to the server is different from that we receive. The best option
would probably be to construct a valid server response (locally) and
pass it off to ERC-PARSE-SERVER-RESPONSE.
How display works:
There are two reasons ERC can display something to the screen,
firstly, we receive external input, secondly, we send some input from
the user.
The way we handle display is as follows:
1) Is the input external, if yes, go to 3), else go to 2)
2) Construct a correct IRC command from the input, send it to the
server, pretend the input is external and go to 1)
3) Parse the input into an ERC-MESSAGE, this may involve setting the
DISPLAYP flag, or any amount of massaging to make the displayable
STRING what we want. Go to 4).
4) If the DISPLAYP flag is non-nil, insert STRING into BUFFERS.
This should hopefully simplify display significantly from the slightly
spaghetti-like affair we have at the moment.
Lawrence
--
Lawrence Mitchell <s01...@sm...>
|
|
From: Stephan S. <st...@eo...> - 2004-12-21 22:54:40
|
Hi. J.Alejandro Noli said: > How can I show on different splitted frame, the differents channels that I log > into at startup ? I guess you should take a look at: C-h v erc-join-buffer erc-join-buffer's value is buffer Determines how to display the newly created IRC buffer. 'window - in another window, 'window-noselect - in another window, but don't select that one, 'frame - in another frame, 'bury - bury it in a new buffer, any other value - in place of the current buffer You can customize this variable. Defined in `erc'. -- Stephan Stahl |
|
From: J. A. N. <ale...@ja...> - 2004-12-21 22:20:26
|
Hi, How can I show on different splitted frame, the differents channels that I log into at startup ? Thanks. Hoan Ton-That <ho...@to...> writes: > Hello, > > If `erc-log-channels-directory' is set to a directory which contains > uppercase characters then logging will not work. The function > `erc-current-logfile' downcases everything including the directory > part. The following simple patch fixes this bug. > > -- Saludos, - J. Alejandro Noli - ~~~~~~~~~~~~~~~~~~~~~ |
|
From: Adrian A. <ad...@xe...> - 2004-12-16 22:35:41
|
CVS erc is broken for me after a cvs update.
This fixes things so that my trusted setup works again.
Could someone please commit this.
Best regards,
Adrian
ChangeLog addition:
2004-12-16 Adrian Aichner <ad...@xe...>
* erc-track.el (erc-track-position-in-mode-line): Check for
'erc-track-mode variable with boundp.
erc source patch:
Diff command: cvs -f -z3 -q diff -u -w -N
Files affected: erc-track.el
Index: erc-track.el
===================================================================
RCS file: /cvsroot/erc/erc/erc-track.el,v
retrieving revision 1.68
diff -u -w -r1.68 erc-track.el
--- erc-track.el 11 Dec 2004 20:37:51 -0000 1.68
+++ erc-track.el 16 Dec 2004 22:31:24 -0000
@@ -177,7 +177,7 @@
(const :tag "After all other information" nil))
:set (lambda (sym val)
(set sym val)
- (when (and (fboundp 'erc-track-mode)
+ (when (and (boundp 'erc-track-mode)
erc-track-mode)
(erc-track-remove-from-mode-line)
(erc-track-add-to-mode-line val))))
--
Adrian Aichner
mailto:ad...@xe...
http://www.xemacs.org/
|
|
From: Jorgen S. <fo...@fo...> - 2004-12-14 14:09:20
|
disumu <ds...@mu...> writes:
> So I ended up making ERC work with the existing mode-line, only
> changing the values of `mode-line-buffer-identification' and
> `mode-line-process'. That's the way many other programs do
> things as well.
You rock. That's what should've been done a long time ago. I was
just too lazy.
Thanks!
Greetings,
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: Hoan Ton-T. <ho...@to...> - 2004-12-14 08:53:47
|
Adrian Aichner <ad...@xe...> writes: > Hoan Ton-That <ho...@to...> writes: > >> Hello, >> >> If `erc-log-channels-directory' is set to a directory which contains >> uppercase characters then logging will not work. The function >> `erc-current-logfile' downcases everything including the directory >> part. The following simple patch fixes this bug. > > Hello Hoan, that explains the first hunk of your patch. > > Why are you throwing out all these occurences of expand-file-name in > other functions which produce file paths based on > erc-log-channels-directory ? > Suppose that `erc-generate-log-file-name-function' is set to `erc-generate-log-file-name-short' and that function is defines as before. Then if `erc-current-logfile' is called on any buffer, `erc-generate-log-file-name-short' will generate a fully expanded pathname. This pathname will be downcased, which includes the directory. Therefore those generation functions should not expand the filename. The expansion takes place in `erc-current-logfile'. |
|
From: disumu <ds...@mu...> - 2004-12-14 07:00:22
|
Hi all,
The last change made to `erc-mode-line-format' (in revision 1.706)
caused an error to occur in Xemacs when loading erc.el. It can't/won't
handle #(" "...) strings.
I tried using `propertize' instead of strings like the one above, but
then some parts of the mode-line didn't work at all (for example, lots
of dashes were missing). So I ended up making ERC work with the
existing mode-line, only changing the values of
`mode-line-buffer-identification' and `mode-line-process'. That's the
way many other programs do things as well.
Note that if you've set `erc-mode-line-format' or
`erc-header-line-format' to something other than the default, you'll
need to change the value to a string that will work with
`format-spec'. The docstring for `erc-mode-line-format' has a list of
the characters which are replaced.
--
disumu
|
|
From: Adrian A. <ad...@xe...> - 2004-12-13 18:29:41
|
Hoan Ton-That <ho...@to...> writes: > Hello, > > If `erc-log-channels-directory' is set to a directory which contains > uppercase characters then logging will not work. The function > `erc-current-logfile' downcases everything including the directory > part. The following simple patch fixes this bug. Hello Hoan, that explains the first hunk of your patch. Why are you throwing out all these occurences of expand-file-name in other functions which produce file paths based on erc-log-channels-directory ? Adrian > > > --- erc-log.el~ 2004-12-13 21:08:44.000000000 +1100 > +++ erc-log.el 2004-12-13 21:08:04.000000000 +1100 > @@ -269,20 +269,19 @@ > If BUFFER is nil, the value of `current-buffer' is used. > This is determined by `erc-generate-log-file-name-function'. > The result is converted to lowercase, as IRC is case-insensitive" > - (downcase (expand-file-name > - (funcall erc-generate-log-file-name-function > + (expand-file-name > + (downcase (funcall erc-generate-log-file-name-function > (or buffer (current-buffer)) > (or (erc-default-target) (buffer-name buffer)) > (erc-current-nick) > - erc-session-server erc-session-port)))) > - > + erc-session-server erc-session-port)) > + erc-log-channels-directory)) > + > (defun erc-generate-log-file-name-with-date (buffer &rest ignore) > "This function computes a short log file name. > The name of the log file is composed of BUFFER and the current date. > This function is a possible value for `erc-generate-log-file-name-function'." > - (expand-file-name > - (concat (buffer-name buffer) "-" (format-time-string "%Y-%m-%d") ".txt") > - erc-log-channels-directory)) > + (concat (buffer-name buffer) "-" (format-time-string "%Y-%m-%d") ".txt")) > > (defun erc-generate-log-file-name-short (buffer &rest ignore) > "This function computes a short log file name. > @@ -290,8 +289,7 @@ > you can affect that using `rename-buffer' and the-like. This > function is a possible value for > `erc-generate-log-file-name-function'." > - (expand-file-name (concat (buffer-name buffer) ".txt") > - erc-log-channels-directory)) > + (concat (buffer-name buffer) ".txt")) > > (defun erc-generate-log-file-name-long (buffer target nick server port) > "Generates a log-file name in the way ERC always did it. > @@ -303,8 +301,7 @@ > ((numberp port) > (number-to-string port))) ".txt"))) > ;; we need a make-safe-file-name function. > - (expand-file-name (convert-standard-filename file) > - erc-log-channels-directory))) > + (convert-standard-filename file))) > > ;;;###autoload > (defun erc-save-buffer-in-logs (&optional buffer) -- Adrian Aichner mailto:ad...@xe... http://www.xemacs.org/ |
|
From: Alex S. <al...@em...> - 2004-12-12 00:51:21
|
"It's me FKtPp ;)" <m_...@16...> writes: > If you mind I post other mail on the gmane.emacs.erc.general Group? You can post anywhere you want, as long as I get it. :) Is gmane.emacs.erc.general redirected to erc...@li...? Otherwise use my wiki to post a note. Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fifth law: OOO Never accept more work than you can handle in one night of hacking. |
|
From: Brian P. <bp...@re...> - 2004-12-11 09:39:32
|
I got a bug report about having to do a /ctcp nick VERSION instead of /ctcp nick version (and similar). Apparently other clients (such as bitchx) automatically upcase the ctcp command. It's not clear to me that is a technically correct thing to do, looking at the various specs on irchelp, but it certainly strikes me as more convention, and the likelihood that someone would expect 'version' to do something other than 'VERSION' strikes me as low. I'm proposing the below patch. Feedback would be welcome; otherwise I'll commmit it soon. Index: erc.el =================================================================== RCS file: /cvsroot/erc/erc/erc.el,v retrieving revision 1.705 diff -r1.705 erc.el < (cond < (tgt < (erc-log (format "erc-send-CTCP-notice: [%s] %s" tgt l)) < (erc-send-command (format "NOTICE %s :\C-a%s\C-a" tgt l) force)))) --- > (let ((l (upcase l))) > (cond > (tgt > (erc-log (format "erc-send-CTCP-notice: [%s] %s" tgt l)) > (erc-send-command (format "NOTICE %s :\C-a%s\C-a" tgt l) force))))) -- I'm awfully glad I'm a Beta, because I don't work so hard. |
|
From: It's me F. ;) <m_...@16...> - 2004-12-10 04:48:25
|
Sorry, but, It seemed that your mail server is blocking my mail :'( ,---- | This message is generated by COREMAIL email system. | I'm sorry to have to inform you that the message returned | | The message to al...@em... is bounced because: | SMTP error, RCPT TO: 554 Service unavailable; Sender address [m_...@16...] blocked using dsn.rfc-ignorant.org; Not supporting null originator (DSN) | | Äã·¢Ë͵½al...@em...µÄÓʼþÓÉÓÚÒÔÏÂÔÒò±»ÍË»Ø: | SMTP error, RCPT TO: 554 Service unavailable; Sender address [m_...@16...] blocked using dsn.rfc-ignorant.org; Not supporting null originator (DSN) `---- If you mind I post other mail on the gmane.emacs.erc.general Group? |
197 messages has been excluded from this view by a project administrator.
