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...> - 2004-05-20 16:38:22
|
Adrian Aichner <ad...@xe...> writes: >> Doesn't e21 have a feature to automatically remove certain text >> properties when killing-and-saving text? If something like that > > Would XEmacs' > buffer-substring-no-properties > come to mind here? Emacs has it as well, but killing and yanking currently keeps text properties, which is sometimes annoying. Another example: <foo> blabla <bar> http://cool/site <baz> please repost ERC> When bar now looks at his buffer and decides to copy the buttonized URL from his previous post, he cannot hit RET and send it, because there is a text-property on the button, which is yanked together with the URL with a local keymap that binds RET to something different. Minor annoyances, to be sure. Using buffer-substring-no-properties is no real solution unless we want to reimplement all killing functions and locally bind them to the default keys in erc-mode. That would suck majorly. Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Adrian A. <ad...@xe...> - 2004-05-18 19:45:14
|
Alex Schroeder <al...@em...> writes: > luis fernandes <el...@ee...> writes: > >> Another alternative would be to have a 1-line window above the >> minibuffer into which input is typed the erc minibuffer, so to >> speak. This buffer would grow and shrink to accomodate the input. > > Doesn't e21 have a feature to automatically remove certain text > properties when killing-and-saving text? If something like that Would XEmacs' buffer-substring-no-properties come to mind here? > would work, then maybe we can have both... > > Alex. -- Adrian Aichner mailto:ad...@xe... http://www.xemacs.org/ |
|
From: Andreas S. <sc...@su...> - 2004-05-18 01:06:27
|
Alex Schroeder <al...@em...> writes: > luis fernandes <el...@ee...> writes: > >> Another alternative would be to have a 1-line window above the >> minibuffer into which input is typed the erc minibuffer, so to >> speak. This buffer would grow and shrink to accomodate the input. > > Doesn't e21 have a feature to automatically remove certain text > properties when killing-and-saving text? It happends during yanking (yank-excluded-properties), but it's only available in CVS emacs so far. Andreas. --=20 Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux AG, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany Key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: Alex S. <al...@em...> - 2004-05-18 00:00:49
|
luis fernandes <el...@ee...> writes: > Another alternative would be to have a 1-line window above the > minibuffer into which input is typed the erc minibuffer, so to > speak. This buffer would grow and shrink to accomodate the input. Doesn't e21 have a feature to automatically remove certain text properties when killing-and-saving text? If something like that would work, then maybe we can have both... Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Alex S. <al...@em...> - 2004-05-17 23:58:41
|
Lawrence Mitchell <we...@gm...> writes: > Some kind of rewrite is on my TODO list, but it will > probably have to wait a while That's ok, I'll wait. ;) Good luck for your exams. Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Alex S. <al...@em...> - 2004-05-17 23:58:13
|
Lucas <lu...@fr...> writes: > 15 mai 2004, 17:06 :Alex Schroeder wrote: > >> Do you all agree we need to add something to support notices? > >> 16:55 <kensanata> i wonder -- should ERC print something when we /NOTICE #emacs BUH! >> 16:56 ERC> /NOTICE #emacs BUH! >> 16:56 <kensanata> there's no output in my buffer... :/ >> 16:57 <fledermaus> You didn't see "-kensanata- BUH!" ? >> 16:58 <kensanata> no. > > What is the problem ? I saw it. The problem is the line "ERC> /NOTICE #emacs BUH!" I would have exptected "-kensanata- BUH!" instead. Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Lawrence M. <we...@gm...> - 2004-05-16 14:03:56
|
disumu wrote: > Hi, > Lawrence Mitchell <we...@gm...> wrote: >> Alternately, rather than bashing my head against this, we could >> just use the old `erc-parse-line-from-server' which iirc works >> fine with IPv6 stuff. > I think that's the best for now since there are at least a few other > cases where lines aren't being parsed correctly: I've committed a (slightly ported) version of `erc-parse-line-from-server' as `erc-parse-server-response' to erc-backend. The original `erc-parse-server-response' has been commented out if someone feels like working on it. > - NOTICE AUTH from dancer-ircd and hybrid, the NOTICE from the server > sent upon connection are displayed incorrectly - these are > examples where there's no colon at the beginning of the line > - the CHANLIMIT=#:20 in freenode's 005 message confuses our line > parser, which leads to `erc-server-parameters' being incorrect I hadn't noticed these but yes, they do break too. > Once we're sure everything else is working like before (or better) we > can start optimizing the way we parse lines... -- Lawrence Mitchell <we...@gm...> |
|
From: disumu <di...@us...> - 2004-05-16 13:50:18
|
Hi,
Lawrence Mitchell <we...@gm...> wrote:
> Alternately, rather than bashing my head against this, we could
> just use the old `erc-parse-line-from-server' which iirc works
> fine with IPv6 stuff.
I think that's the best for now since there are at least a few other
cases where lines aren't being parsed correctly:
- NOTICE AUTH from dancer-ircd and hybrid, the NOTICE from the server
sent upon connection are displayed incorrectly - these are
examples where there's no colon at the beginning of the line
- the CHANLIMIT=#:20 in freenode's 005 message confuses our line
parser, which leads to `erc-server-parameters' being incorrect
Once we're sure everything else is working like before (or better) we
can start optimizing the way we parse lines...
--
disumu
|
|
From: Lawrence M. <we...@gm...> - 2004-05-16 12:32:42
|
`erc-parse-server-response' currently does not do the right thing with IPv6 hostmasks. This is mostly me misreading the IRC spec I think. Basically, we need to change our parsing of the server response so that we allow: :nick!user@ipv6:host: command blablabla The thing to do is to probably special-case on the response not starting with a colon. Since then we just have: COMMAND : params : contents For the response starting with a colon we have: :anything-not-a-space-is-the-sender command params : contents Alternately, rather than bashing my head against this, we could just use the old `erc-parse-line-from-server' which iirc works fine with IPv6 stuff. What do people think? -- Lawrence Mitchell <we...@gm...> |
|
From: Adrian A. <ad...@xe...> - 2004-05-16 08:01:18
|
Hi! I am getting this today, still using ERC Version 4.0 $Revision: 1.657 $ ERC FLOOD PROTECT: line not sent: "PRIVMSG NickServ :IDENTIFY PASSWD" Logging in as 'anaran'... done Logging in as 'anaran'... Connecting to irc.freenode.net:6667... ...done Connecting to irc.freenode.net:6667... Any suggestions? -- Adrian Aichner mailto:ad...@xe... http://www.xemacs.org/ |
|
From: luis f. <el...@ee...> - 2004-05-15 23:55:15
|
alex> Is there no better solution instead of adding more text
alex> properties?
My problem is with the ERC prompt "dislodging" from it's usual spot
and accidently moving around in the buffer.
Another alternative would be to have a 1-line window above the
minibuffer into which input is typed the erc minibuffer, so to
speak. This buffer would grow and shrink to accomodate the input.
|
|
From: Alex S. <al...@em...> - 2004-05-15 16:28:56
|
luis fernandes <el...@ee...> writes: > As a suggestion, all the text prior to the prompt should be > immutable. I already hate it that some of the text has funky properties so when i try to use M-w and yank elsewhere (such as a mail buffer), i always have to remember to M-x remove-all-text-properties or feel 30s of aggravation. Is there no better solution instead of adding more text properties? Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Lawrence M. <we...@gm...> - 2004-05-15 15:11:25
|
Alex Schroeder wrote: > Do you all agree we need to add something to support notices? YES! More generally, it would be nice if any kind of /foo command (e.g. /say) actually displayed stuff in the buffer. I think the thing to do here is to display stuff that we send with the same process that we use to display stuff from the server. This would involve some kind of rewriting of the way we do output display. Some kind of rewrite is on my TODO list, but it will probably have to wait a while, since I've already procrastinated doing work for exams enough already really ;). [...] -- Lawrence Mitchell <we...@gm...> |
|
From: Lucas <lu...@fr...> - 2004-05-15 15:07:48
|
15 mai 2004, 17:06 :Alex Schroeder wrote: > Do you all agree we need to add something to support notices? > 16:55 <kensanata> i wonder -- should ERC print something when we /NOTICE #emacs BUH! > 16:56 ERC> /NOTICE #emacs BUH! > 16:56 <kensanata> there's no output in my buffer... :/ > 16:57 <fledermaus> You didn't see "-kensanata- BUH!" ? > 16:58 <kensanata> no. What is the problem ? I saw it. ERC Version 4.0 $Revision: 1.657 $ -- Lucas / Lukhas |
|
From: Alex S. <al...@em...> - 2004-05-15 15:01:58
|
Do you all agree we need to add something to support notices? 16:55 <kensanata> i wonder -- should ERC print something when we /NOTICE #emacs BUH! 16:56 ERC> /NOTICE #emacs BUH! 16:56 <kensanata> there's no output in my buffer... :/ 16:57 <fledermaus> You didn't see "-kensanata- BUH!" ? 16:58 <kensanata> no. Compare to other people: 16:59 <Han> buh 16:59 -Han- buh 16:59 <Han> whee Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: luis f. <el...@ee...> - 2004-05-15 02:56:28
|
I'm using ERC Version 4.0 $Revision: 1.517 $ with Emacs 21.1.1 on Windows XP. At the erc prompt, "ERC>", do the following: C-p C-e C-d RET The prompt moves to the previous line and the display becomes confusing...how do i get out of this? can i just press RET? As a suggestion, all the text prior to the prompt should be immutable. |
|
From: Lawrence M. <we...@gm...> - 2004-05-14 23:34:49
|
Adrian Aichner wrote: > Lawrence Mitchell <we...@gm...> writes: >> Edward O'Connor wrote: >> [...] >>> This isn't just a help-Lawrence-out thing; the new code breaks quite >>> thoroughly when byte-compiled. FYI. It seems to be an issue with using >>> `erc-with-buffer' in `define-erc-response-handler' forms. >>> `erc-with-buffer' is defined as a macro in erc.el, which is not >>> `require'd by erc-backend.el (in fact, it's quite the opposite). So this >>> `erc-with-buffer' is being byte-compiled as a function call. >> Ah, well, spotted Ted. Suggestions for clean fixes people? I >> can move the various macros in erc.el into erc-backend, but >> that's probably a bad idea, since it then dilutes the purpose of >> it. Possibly, moving the (provide 'erc-backend) to the top of > Please don't do that! > Keeping the (provide ...) at the end will give an immediate clue that > something went wrong during eval of erc-backend.el. I've now committed a (temporary) fix for this by autoloading erc-with-buffer as a macro from erc.el at the top of erc-backend. I still think the best thing to do is to move macros into a separate file, which one can require without having recursive-require nightmares and bootstrapping problems. I've further committed a fix for erc-parse-server-response which actually makes it /work/ in XEmacs, this was due to a "feature" in XEmacs' `replace-match', which only replaces subexpressions when operating on buffers, not strings. Hopefully there aren't any more nasty bugs like this lurking around (yeah right). [...] -- Lawrence Mitchell <we...@gm...> |
|
From: Alex S. <al...@em...> - 2004-05-14 19:57:13
|
Jeremy Maitin-Shepard <jb...@at...> writes: > Lawrence Mitchell <we...@gm...> writes: > >> [snip] > >>> well, I think I've just about ported all of ERC to a new backend >>> interface (I've been running without error for a few hours now). >>> erc-members.el has /not/ been ported, I think this is obsolete >>> anyway, with the advent of jbms' hashtable channel-members stuff. > >> Anyone have any comments on this? > > Yes, erc-members.el certainly doesn't need to be maintained. I believe > it was designed to do the same thing as my hash table patch does, but > it doesn't appear to be complete, nor does it appear that it was ever > actually used. Yes. Please remove it. Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's fourth law: OOO None of your friends and coworkers share your taste in music. |
|
From: Adrian A. <ad...@xe...> - 2004-05-14 19:47:29
|
Lawrence Mitchell <we...@gm...> writes: > Edward O'Connor wrote: > > [...] > >> This isn't just a help-Lawrence-out thing; the new code breaks quite >> thoroughly when byte-compiled. FYI. It seems to be an issue with using >> `erc-with-buffer' in `define-erc-response-handler' forms. >> `erc-with-buffer' is defined as a macro in erc.el, which is not >> `require'd by erc-backend.el (in fact, it's quite the opposite). So this >> `erc-with-buffer' is being byte-compiled as a function call. > > Ah, well, spotted Ted. Suggestions for clean fixes people? I > can move the various macros in erc.el into erc-backend, but > that's probably a bad idea, since it then dilutes the purpose of > it. Possibly, moving the (provide 'erc-backend) to the top of Please don't do that! Keeping the (provide ...) at the end will give an immediate clue that something went wrong during eval of erc-backend.el. > erc-backend.el above the (require 'erc) fixes things, but that's > not really very elegant, or "obvious". A more sensible idea > would probably be to pull all the macros out into erc-macs.el > (say), though I'm not sure if what's currently in that file is > ever used. -- Adrian Aichner mailto:ad...@xe... http://www.xemacs.org/ |
|
From: Lawrence M. <we...@gm...> - 2004-05-14 12:26:11
|
Lawrence Mitchell wrote: > Edward O'Connor wrote: >> This isn't just a help-Lawrence-out thing; the new code breaks quite >> thoroughly when byte-compiled. FYI. It seems to be an issue with using >> `erc-with-buffer' in `define-erc-response-handler' forms. >> `erc-with-buffer' is defined as a macro in erc.el, which is not >> `require'd by erc-backend.el (in fact, it's quite the opposite). So this >> `erc-with-buffer' is being byte-compiled as a function call. Does this patch fix things temporarily until I can think of a cleaner fix? Index: erc-backend.el =================================================================== RCS file: /cvsroot/erc/erc/erc-backend.el,v retrieving revision 1.1 diff -u -r1.1 erc-backend.el --- erc-backend.el 13 May 2004 17:30:10 -0000 1.1 +++ erc-backend.el 14 May 2004 12:24:20 -0000 @@ -95,8 +95,8 @@ ;; new interface. ;;; Code: - (require 'cl) +(autoload 'erc-with-buffer "erc" nil nil 'macro) (defconst erc-backend-version "$Revision: 1.1 $") [...] -- Lawrence Mitchell <we...@gm...> |
|
From: Lawrence M. <we...@gm...> - 2004-05-14 10:13:21
|
Edward O'Connor wrote: [...] > This isn't just a help-Lawrence-out thing; the new code breaks quite > thoroughly when byte-compiled. FYI. It seems to be an issue with using > `erc-with-buffer' in `define-erc-response-handler' forms. > `erc-with-buffer' is defined as a macro in erc.el, which is not > `require'd by erc-backend.el (in fact, it's quite the opposite). So this > `erc-with-buffer' is being byte-compiled as a function call. Ah, well, spotted Ted. Suggestions for clean fixes people? I can move the various macros in erc.el into erc-backend, but that's probably a bad idea, since it then dilutes the purpose of it. Possibly, moving the (provide 'erc-backend) to the top of erc-backend.el above the (require 'erc) fixes things, but that's not really very elegant, or "obvious". A more sensible idea would probably be to pull all the macros out into erc-macs.el (say), though I'm not sure if what's currently in that file is ever used. -- Lawrence Mitchell <we...@gm...> |
|
From: Edward O'C. <te...@oc...> - 2004-05-14 04:37:28
|
Lawrence wrote, on his recent erc-backend work: > Please run with uncompiled code and with debug-on-error set to t. This isn't just a help-Lawrence-out thing; the new code breaks quite thoroughly when byte-compiled. FYI. It seems to be an issue with using `erc-with-buffer' in `define-erc-response-handler' forms. `erc-with-buffer' is defined as a macro in erc.el, which is not `require'd by erc-backend.el (in fact, it's quite the opposite). So this `erc-with-buffer' is being byte-compiled as a function call. Ted -- Edward O'Connor te...@oc... Ense petit placidam sub libertate quietem. |
|
From: Jeremy Maitin-S. <jb...@at...> - 2004-05-14 00:53:38
|
Lawrence Mitchell <we...@gm...> writes: > [snip] >> well, I think I've just about ported all of ERC to a new backend >> interface (I've been running without error for a few hours now). >> erc-members.el has /not/ been ported, I think this is obsolete >> anyway, with the advent of jbms' hashtable channel-members stuff. > Anyone have any comments on this? Yes, erc-members.el certainly doesn't need to be maintained. I believe it was designed to do the same thing as my hash table patch does, but it doesn't appear to be complete, nor does it appear that it was ever actually used. > [snip] -- Jeremy Maitin-Shepard |
|
From: Lawrence M. <we...@gm...> - 2004-05-13 18:12:48
|
Lawrence Mitchell wrote: Right, I've now committed, should you not wish to run around with a buggy ERC, you can get the pre-changes tree by checking out files with the PRE_NEW_BACKEND symbolic tag (only those that I had to change have this tag, some files are unchanged). > well, I think I've just about ported all of ERC to a new backend > interface (I've been running without error for a few hours now). > erc-members.el has /not/ been ported, I think this is obsolete > anyway, with the advent of jbms' hashtable channel-members stuff. Anyone have any comments on this? [...] > All server response handlers should be defined with > `deferc-response-handler'. This defines functions and > corresponding hook variables. This is now define-erc-response-handler, it works exactly the same way though. [...] > (gethash (format (if (numberp command) "%03i" "%s") command) > erc-server-responses) > This will get a wrapper function, it doesn't have one yet. It has one, it's called `erc-get-hook', and takes as an argument, a server command, e.g. "MOTD", or a numeric response, e.g. 001. [...] This warning still applies :) > WARNING WARNING!! > I have not tested the new code with all bits of ERC, I've put > FIXMEs in a bunch of places where I'm not sure I correctly > interpreted the previous implementation's magic numbers (I > haven't waded through the IRC spec in great detail, lots of it > has been a trial-and-error thing). Please run with uncompiled > code and with debug-on-error set to t. The backtrace will > generally contain a complete `erc-response' struct, a copy of > this, and which ERC function caused the error are the two bits > of information most needed to fix things. I just compare what > the old code did with what the new code does with that test > case. -- Lawrence Mitchell <we...@gm...> |
|
From: Lawrence M. <we...@gm...> - 2004-05-11 22:24:18
|
Hi people,
well, I think I've just about ported all of ERC to a new backend
interface (I've been running without error for a few hours now).
erc-members.el has /not/ been ported, I think this is obsolete
anyway, with the advent of jbms' hashtable channel-members stuff.
Should you not want to test this stuff, I shall symbolically tag
the tree before I commit, and tell people what the tag is. But
please do :).
Major changes for implementors are:
o `erc-parse-line-from-server' is gone.
It's replaced with `erc-parse-server-response'. In the same
vein, 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
`deferc-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:
(gethash (format (if (numberp command) "%03i" "%s") command)
erc-server-responses)
This will get a wrapper function, it doesn't have one yet.
See the docstring of `deferc-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 (I hope), but external module authors should beware.
Things that still need to be done (straight from the TODO list
in erc-backend):
o Rip out the sending commands stuff from erc.el and rewrite it in
a slightly more abstracted fashion. That should probably go in
here too.
o Generalise the display-line code so that we can use it to
display the stuff we send, as well as the stuff we receive.
Then, move all display-related code into another backend-like
file, erc-display.el, say.
o Clean up the handlers using new display code (has to be written
first).
WARNING WARNING!!
I have not tested the new code with all bits of ERC, I've put
FIXMEs in a bunch of places where I'm not sure I correctly
interpreted the previous implementation's magic numbers (I
haven't waded through the IRC spec in great detail, lots of it
has been a trial-and-error thing). Please run with uncompiled
code and with debug-on-error set to t. The backtrace will
generally contain a complete `erc-response' struct, a copy of
this, and which ERC function caused the error are the two bits
of information most needed to fix things. I just compare what
the old code did with what the new code does with that test
case.
Comments, further suggestions?
Lawrence
--
Lawrence Mitchell <we...@gm...>
|
197 messages has been excluded from this view by a project administrator.
