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...@gn...> - 2003-06-11 20:51:38
|
Francis Litterio <fr...@wo...> writes: > Marcelo Toledo wrote: > >> We could limit the messages only for members what do you guys think ? > > Most mailing lists do that to block spam. I'm for it. I rarely see spam. Therefore I'm against it, because it makes bug reporting harder. The BBDB mailing list did that because of the spam volume (which I didn't see), so it is not unheard of to ignore me in this respect. ;) Alex. -- http://www.emacswiki.org/cgi-bin/alex.pl |
|
From: Francis L. <fr...@wo...> - 2003-06-11 14:55:06
|
Marcelo Toledo wrote: > We could limit the messages only for members what do you guys think ? Most mailing lists do that to block spam. I'm for it. -- Francis Litterio fr...@wo... http://world.std.com/~franl/ GPG and PGP public keys available on keyservers. |
|
From: Max F. <mf...@w3...> - 2003-06-04 04:39:46
|
Alex Schroeder <al...@gn...> wrote: > Hm, how strange... resolve reported the same thing, but it worked > for me. resolve then found that he had not updated erc-compat.el; > could that be the same problem for you? I had updated everything. It worked again after I removed all the elc files and then compiled again, which indeed removed erc-compat.elc. I don't know what was going on exactly but it seems to work again now. Max. |
|
From: Alex S. <al...@gn...> - 2003-06-03 23:59:52
|
Max Froumentin <mf...@w3...> writes: > Max Froumentin <mf...@w3...> wrote: > >> This breaks ERC running in emacs in terminal mode. On connect, I get: > > Actually, this break my ERC even running in X11. Hm, how strange... resolve reported the same thing, but it worked for me. resolve then found that he had not updated erc-compat.el; could that be the same problem for you? Alex. -- http://www.emacswiki.org/cgi-bin/alex.pl |
|
From: Max F. <mf...@w3...> - 2003-06-03 14:45:03
|
Max Froumentin <mf...@w3...> wrote: > This breaks ERC running in emacs in terminal mode. On connect, I get: Actually, this break my ERC even running in X11. Max. |
|
From: Max F. <mf...@w3...> - 2003-06-03 13:45:32
|
Hannu Koivisto <az...@ik...> wrote: > A few old changes I never got around to sending until now. Regexps > are used to match targets in erc-encoding-coding-alist and decoding > is symmetric with encoding; This breaks ERC running in emacs in terminal mode. On connect, I get: "error in process filter: erc-decode-string-from-target: Wrong number of argumen\ ts: #[(s) "\301^H\302\303#\207" [s decode-coding-string undecided t] 4 "Decode \ characters. The correct coding system is guessed by Emacs."], 2 error in process filter: Wrong number of arguments: #[(s) "\301^H\302\303#\207"\ [s decode-coding-string undecided t] 4 "Decode characters. The correct coding\ system is guessed by Emacs."]" Max. |
|
From: Damien E. <re...@re...> - 2003-06-01 13:01:38
|
Alex Schroeder <al...@gn...> writes: > I tried grepping for "The correct coding system is guessed by Emacs." > and "correct coding system" but found no match. I don't know where > you lambda (s) comes from. Any ideas? That is definitely a bug, but > it seems to be some config of yours... Well, the problem seems to have gone away. I suspect what happened is that erc.el was updated (merging in part of the change) when I commited Mark's fix the other day, but erc-compat.el wasn't updated. A cvs up seems to have solved the problem. Whoops! Cheers, -- Damien Elmes |
|
From: Hannu K. <az...@ik...> - 2003-06-01 10:18:20
|
Alex Schroeder <al...@gn...> writes: > Thanks for the patch. I have applied it. Did you already sign > papers for ERC? Since ERC is not yet part of Emacs, you need to sign I haven't signed any papers. Feel free to send me whatever papers are needed (plus a return envelope with enough stamps to get it from Finland to wherever it is supposed to go). I'll mail my address privately. Alex Schroeder <al...@gn...> writes: > Hannu Koivisto <az...@ik...> writes: > >> A few old changes I never got around to sending until now. Regexps >> are used to match targets in erc-encoding-coding-alist and decoding >> is symmetric with encoding > > Hm. It is no longer possible to use one encoding and a different > decoding -- using the coding-system 'undecided had the benefit of > doing the right thing most of the time. I must think about this some > more. Haven't seen any problems until now... :) That is correct. I recall I originally had separate default coding systems for input and output (maybe also erc-decoding-coding-alist aside erc-encoding-coding-alist) but I think I changed that because I considered coding system to be target-specific and didn't see any reason to use a different coding system for input than for output. However, now that you mentioned it, using a defaulting coding system for input may be useful while using it for output is not, so this is clearly such a reason that I missed. -- Hannu |
|
From: Alex S. <al...@gn...> - 2003-06-01 08:36:12
|
Hannu Koivisto <az...@ik...> writes: > A few old changes I never got around to sending until now. Regexps > are used to match targets in erc-encoding-coding-alist and decoding > is symmetric with encoding Hm. It is no longer possible to use one encoding and a different decoding -- using the coding-system 'undecided had the benefit of doing the right thing most of the time. I must think about this some more. Haven't seen any problems until now... :) Alex. -- http://www.emacswiki.org/cgi-bin/alex.pl |
|
From: Alex S. <al...@gn...> - 2003-06-01 08:32:53
|
Damien Elmes <erc...@re...> writes:
> Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (s) "Decode
> characters. The correct coding system is guessed by Emacs."
> (decode-coding-string s (quote undecided) t)) 2)
>
> erc-decode-coding-string("*** If you are having problems connecting due to
> ping timeouts, please type /raw pong 859F9457 or /quote pong 859F9457 now."
> ctext)
>
> erc-decode-string-from-target("*** If you are having problems connecting due
> to ping timeouts, please type /raw pong 859F9457 or /quote pong 859F9457
> now." "irc.netspace.net.au")
I tried grepping for "The correct coding system is guessed by Emacs."
and "correct coding system" but found no match. I don't know where
you lambda (s) comes from. Any ideas? That is definitely a bug, but
it seems to be some config of yours...
Alex.
--
http://www.emacswiki.org/cgi-bin/alex.pl
|
|
From: Damien E. <erc...@re...> - 2003-06-01 04:07:15
|
Alex Schroeder <al...@gn...> writes:
> Mario Lang <ml...@de...> writes:
>
>>> erc-encode-coding-string would be defaliased to ignore, which only
>>> takes one argument.
>>
>> AFAIK, ignore is &rest ignore
>
> Yeah, my mistake -- it was defaliased to 'identity, which only takes
> one argument.
Okay, here we go:
Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (s) "Decode
characters. The correct coding system is guessed by Emacs."
(decode-coding-string s (quote undecided) t)) 2)
erc-decode-coding-string("*** If you are having problems connecting due to
ping timeouts, please type /raw pong 859F9457 or /quote pong 859F9457 now."
ctext)
erc-decode-string-from-target("*** If you are having problems connecting due
to ping timeouts, please type /raw pong 859F9457 or /quote pong 859F9457
now." "irc.netspace.net.au")
Regards,
--
Damien Elmes
|
|
From: Alex S. <al...@gn...> - 2003-05-31 14:52:12
|
Mario Lang <ml...@de...> writes: >> erc-encode-coding-string would be defaliased to ignore, which only >> takes one argument. > > AFAIK, ignore is &rest ignore Yeah, my mistake -- it was defaliased to 'identity, which only takes one argument. -- http://www.emacswiki.org/cgi-bin/alex.pl |
|
From: Mario L. <ml...@de...> - 2003-05-31 14:34:11
|
Alex Schroeder <al...@gn...> writes: [...] > erc-encode-coding-string would be defaliased to ignore, which only > takes one argument. AFAIK, ignore is &rest ignore -- CYa, Mario |
|
From: Damien E. <re...@re...> - 2003-05-31 14:16:46
|
Alex Schroeder <al...@gn...> writes: > Strange. A grep reveiled that if you had no encode-coding-string, > erc-encode-coding-string would be defaliased to ignore, which only > takes one argument. So I fixed that. But your system should have an > encode-coding-string... I'm using emacs-cvs - I've got the three argument version. What I meant before is that something is calling erc-encode-coding-string with more than one arg, not encode-coding-string. Sorry for the confusion :-) Regards, -- Damien Elmes |
|
From: Alex S. <al...@gn...> - 2003-05-31 14:07:22
|
Damien Elmes <erc...@re...> writes:
> This seems to have broken something - something is calling
> erc-decode-coding-string with multiple arguments, and it only accepts one. I
> don't have time to look into it at the moment, instead rolling back with:
>
> mobile[1]% cvs -z3 up -PAd -D "2 days ago"
Strange. A grep reveiled that if you had no encode-coding-string,
erc-encode-coding-string would be defaliased to ignore, which only
takes one argument. So I fixed that. But your system should have an
encode-coding-string...
This is what I did:
*** erc-compat.el.~1.11.~ 2003-05-29 21:12:09.000000000 +0200
--- erc-compat.el 2003-05-31 16:04:39.000000000 +0200
***************
*** 82,88 ****
(decode-coding-string s coding-system)))
(error
;; Default
! (defalias 'erc-decode-coding-string 'identity)))))
(condition-case nil
;; Try 3 arguments
--- 82,90 ----
(decode-coding-string s coding-system)))
(error
;; Default
! (defun erc-decode-coding-string (s &rest ignore)
! "Return S."
! s)))))
(condition-case nil
;; Try 3 arguments
Alex.
--
http://www.emacswiki.org/cgi-bin/alex.pl
|
|
From: Damien E. <erc...@re...> - 2003-05-31 10:54:49
|
Alex Schroeder <al...@gn...> writes: > Thanks for the patch. I have applied it. This seems to have broken something - something is calling erc-decode-coding-string with multiple arguments, and it only accepts one. I don't have time to look into it at the moment, instead rolling back with: mobile[1]% cvs -z3 up -PAd -D "2 days ago" Regards, -- Damien Elmes |
|
From: Mario L. <ml...@de...> - 2003-05-30 23:53:35
|
ar...@rf... writes: > I have done a small patch for erc: > > below is a cvs diff -u Thanks, applied. -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger ml...@db... | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 |
|
From: <ar...@rf...> - 2003-05-30 23:21:45
|
I have done a small patch for erc:
below is a cvs diff -u
? ChangeLog
? diff
Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.527
diff -u -r1.527 erc.el
--- erc.el 15 May 2003 16:39:31 -0000 1.527
+++ erc.el 29 May 2003 21:55:59 -0000
@@ -3749,6 +3749,7 @@
(306 erc-server-306)
(311 erc-server-311-or-314)
(312 erc-server-312)
+ (313 erc-server-313)
(314 erc-server-311-or-314)
(315 ignore)
(317 erc-server-317)
@@ -3759,6 +3760,7 @@
(322 erc-server-322)
(324 erc-server-324)
(329 erc-server-329)
+ (330 erc-server-330)
(331 erc-server-331)
(332 erc-server-332)
(333 erc-server-333)
@@ -4278,7 +4280,14 @@
(format "%s is/was on server %s (%s)"
nick saddr server))))
-(defvar erc-server-313-hook nil)
+(defun erc-server-313 (proc parsed)
+ ;; Irc Oper in whois
+ (let ((nick (aref parsed 3))
+ (ircopermsg (aref parsed 4)))
+ (erc-display-message
+ parsed 'notice 'active
+ (format "%s %s" nick ircopermsg))))
+
(defvar erc-server-315-hook nil)
(defun erc-server-317 (proc parsed)
@@ -4356,6 +4365,16 @@
parsed 'notice (erc-get-buffer chnl proc)
's329 ?c chnl ?t (format-time-string "%A %Y-%m-%d %X" time))))
+(defun erc-server-330 (proc parsed)
+ ;; Authed as in whois (quakenet)
+ (let ((nick (aref parsed 3))
+ (authaccount (aref parsed 4))
+ (authmsg (aref parsed 5)))
+ (erc-display-message
+ parsed 'notice 'active
+ (format "%s %s %s"
+ nick authmsg authaccount))))
+
(defun erc-server-331 (proc parsed)
;; Channel topic
(let ((chnl (aref parsed 3))
|
|
From: Alex S. <al...@gn...> - 2003-05-29 19:30:58
|
Thanks for the patch. I have applied it. Did you already sign papers for ERC? Since ERC is not yet part of Emacs, you need to sign separate papers for ERC, or if you signed papers for Emacs, you must send mail stating "My copyright assignments for Emacs also apply to all changes to ERC" to Jessica Natale <nat...@fs...>. Is that Ok for you? Alex. -- http://www.emacswiki.org/cgi-bin/alex.pl |
|
From: Hannu K. <az...@ik...> - 2003-05-29 16:52:20
|
Greetings, A few old changes I never got around to sending until now. Regexps are used to match targets in erc-encoding-coding-alist and decoding is symmetric with encoding; a new erc-decode-string-from-target was introduced for decoding strings in a target (or source, depending on which way you look at it) specific manner and both it and erc-encode-string-for-target default to using erc-default-coding-system, previously called erc-encoding-default. Instead of blindly decoding all data coming from server, only relevant data is decoded (it may be that everything is not covered yet). The rest of the changes can be considered cosmetic. 2003-05-29 Hannu Koivisto <az...@ik...> * erc.el: * (erc-select) server is now defaulted with erc-compute-server. A few cosmetic fixes. * (erc-default-coding-system) Renamed from erc-encoding-default. * (erc-encoding-default) Renamed to erc-default-coding-system. * (erc-encoding-coding-alist) Documentation updated to cover regexps. * (erc-encode-string-for-target) Now considers keys of erc-encoding-coding-alist to be regexps. Rely on erc-compat wrt. MULE support. * (erc-decode-string-from-target) New function. * (erc-send-current-line) eq -> char-equal fix. * (erc-server-TOPIC) topic is now decoded with erc-decode-string-from-target. * (erc-parse-line-from-server) Line from server is no longer decoded here. * (erc-server-PRIVMSG-or-NOTICE) Message from a user is decoded here, sspec -> sender-spec for clarity. Cosmetic if -> when fix. * (erc-server-TOPIC) sspec -> sender-spec * (erc-server-WALLOPS) Ditto. * erc-compat.el: * (erc-decode-coding-string) Now requires coding-system as an argument. -- Hannu |
|
From: Marcelo T. <rw...@lo...> - 2003-05-25 11:43:34
|
Hey, Francis Litterio <fr...@wo...> writes: > What happens if the current buffer is not an ERC buffer when a notice > arrives? it will not echo erc messages inside your code hehe... the notice go to the last active buffer of erc... > What happens if you are connection to two networks, and a notice comes > from network A but your active buffer is associated with network B? The notice goes to the last active buffer of A... -- Marcelo Toledo mailto:rw...@lo... http://rw.locked.org Mobile: 55 71 9141-7181 |
|
From: Francis L. <fr...@wo...> - 2003-05-25 02:11:59
|
Marcelo Toledo wrote: > I missed a lot something epic, bitchx, xchat can have so i wrote this > simple patch. It only shows notices in the active buffer so you dont > need to change the buffer to only read a message. Just curious ... What happens if the current buffer is not an ERC buffer when a notice arrives? What happens if you are connection to two networks, and a notice comes from network A but your active buffer is associated with network B? -- Francis Litterio fr...@wo... http://world.std.com/~franl/ GPG and PGP public keys available on keyservers. |
|
From: Marcelo T. <rw...@lo...> - 2003-05-25 01:58:04
|
hi, I missed a lot something epic, bitchx, xchat can have so i wrote this simple patch. It only shows notices in the active buffer so you dont need to change the buffer to only read a message. C-c j #emacs /msg memoserv list Change buffer to read the output... (where i could simply read the output is this same buffer...) here it go: --- erc.el.orig 2003-05-24 15:37:23.000000000 -0400 +++ erc.el 2003-05-24 17:41:42.000000000 -0400 @@ -291,6 +291,11 @@ :group 'erc :type 'boolean) +(defcustom erc-echo-notices-in-current-buffer nil + "*If non-nil, erc will echo arriving notices from IRC in the current buffer." + :group 'erc + :type 'boolean) + (defvar erc-interpret-controls-p t "*Whether to interpret the colors and other highlighting info or not. The interpreting can require a lot of resources and in chatty @@ -4093,7 +4098,9 @@ (when s (when (and noticep privp erc-echo-notices-in-minibuffer-flag) (message "%s" (concat "NOTICE: " s))) - (erc-display-message parsed nil buffer s)))))) + (if (and noticep privp erc-echo-notices-in-current-buffer) + (erc-display-message parsed nil 'active s) + (erc-display-message parsed nil buffer s))))))) (defun erc-server-QUIT (proc parsed) (let* ((reason (aref parsed 2)) comments ? -- Marcelo Toledo mailto:rw...@lo... http://rw.locked.org Mobile: 55 71 9141-7181 |
|
From: lawrence m. <we...@gm...> - 2003-04-25 18:03:45
|
On MS-windows systems, ERC-GENERATE-LOG-FILE-NAME-LONG does the wrong thing with respect to generating allowed file names. Since this function is the default value for ERC-GENERATE-LOG-FILE-NAME-FUNCTION, I feel that it ought to work out of the box on w32 systems. The following (rather icky) patch against current CVS introduces a new variable ERC-W32-INVALID-FILE-CHARACTERS, and adds some extra checking to ERC-GENERATE-LOG-FILE-NAME-LONG. A few queries about this: * Should the replacement character be a variable? * Initialisation of ERC-W32-INVALID-FILE-CHARACTERS is done using the Emacs variable FILE-NAME-INVALID-REGEXP. Is this defined in XEmacs? * ERC-W32-INVALID-FILE-CHARACTERS is only initialised if Emacs is running on a w32 system, this is checked using: (memq system-type '(windows-nt ms-dos cygwin)) Does XEmacs have other system-types to describe w32 systems? * Currently I haven't looked at the rest of ERC to see if invalid file names might be created elsewhere. Is this worthwhile doing? ----- Begin erc.el patch ----- Index: erc.el =================================================================== RCS file: /cvsroot/erc/erc/erc.el,v retrieving revision 1.521 diff -c -r1.521 erc.el *** erc.el 20 Apr 2003 11:55:09 -0000 1.521 --- erc.el 25 Apr 2003 18:02:36 -0000 *************** *** 1133,1138 **** --- 1133,1153 ---- ;; activation + (defconst erc-w32-invalid-file-characters + (if (memq system-type '(windows-nt ms-dos cygwin)) + (let ((regexp file-name-invalid-regexp)) + (when (string-match "^.*\\?\\(:.*\\)" regexp) + (setq regexp (match-string 1 regexp)) + (when (string-match "\\[\\(.*\\)]" regexp) + (setq regexp (concat "[" + (regexp-quote + (concat ":" + (match-string 1 regexp))) + "]")))) + regexp) + nil) + "Regular expression matching invalid file-name characters on w32 systems.") + (defconst erc-default-server "irc.openprojects.net" "IRC server to use if it cannot be detected otherwise.") *************** *** 6401,6410 **** "Generates a log-file name in the way ERC always did it. This results in a file name of the form #channel!nick@server:port.txt. This function is a possible value for `erc-generate-log-file-name-function'." ! (concat erc-log-channels-directory "/" (if target (concat target "!")) ! nick "@" server ":" (cond ((stringp port) port) ! ((numberp port) ! (number-to-string port))) ".txt")) (defun erc-save-buffer-in-logs (&optional buffer) "Append BUFFER contents to the log file, if logging is enabled. --- 6416,6430 ---- "Generates a log-file name in the way ERC always did it. This results in a file name of the form #channel!nick@server:port.txt. This function is a possible value for `erc-generate-log-file-name-function'." ! (let ((file (concat ! (if target (concat target "!")) ! nick "@" server ":" (cond ((stringp port) port) ! ((numberp port) ! (number-to-string port))) ".txt"))) ! (if erc-w32-invalid-file-characters ! (while (string-match erc-w32-invalid-file-characters file) ! (setq file (replace-match "-" nil t file)))) ! (concat erc-log-channels-directory "/" file))) (defun erc-save-buffer-in-logs (&optional buffer) "Append BUFFER contents to the log file, if logging is enabled. ----- end erc.el patch ----- -- lawrence mitchell <we...@gm...> |
|
From: Damien E. <erc...@re...> - 2003-04-17 03:36:20
|
Max Froumentin <mf...@w3...> writes: > [erc.el 1.509] > > After being frustrated at erc not telling me that the directory I > specified in erc-log-channels-directory was wrong, causing it to not > log anything and me to lose precious information, I changed > erc-directory-writable-p to check more things: > > (defun erc-directory-writable-p (dir) > "Determines whether the DIR is a writable directory. If it doesn't exist, > create it." > > (unless (file-attributes dir) (make-directory dir)) > (or (file-accessible-directory-p dir) (error "cannot access %s" dir))) > > Additionally I think logging code could be simplified by removing > erc-log-channels and just use the value of erc-logs-channels-directory > to find out whether we're logging or not. Thanks Max - I've incorporated your suggestions. Regards, -- Damien Elmes |
197 messages has been excluded from this view by a project administrator.
