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: Michael O. <mw...@gn...> - 2005-03-01 18:11:02
|
disumu <ds...@mu...> writes: > But do we need a 5.0 CVS branch anymore at all if any and all > changes made to the development branch are merged to it after it's > been a while since they were added? The merge based on date is a one-time thing for me. The reason for it is that I started my Arch mirror of ERC's CVS HEAD and 5.0 release at 2005-01-19. To obtain a list of the changes that exist in CVS HEAD and not in 5.0, I do something like the following. cd erc-arch-5.0 tla missing erc--cvs-head--0 Any changes made to CVS HEAD before 2005-01-19 would not show up on my list, so I wanted to make sure they weren't forgotten. Also, I *really* wanted to get the active-buffer related changes in, which is what most of those changes were :^) . > If this is the way it's going to be, I don't see any reason for me > to do the extra work anymore ;P Please do continue to use the release branch :^) . I'll try to behave. =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: anime, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Henrik E. <hen...@te...> - 2005-03-01 16:17:13
|
Here's a small patch to make erc-track a bit more cosmetically
pleasing. Currently, it always inserts spaces before and after the
"[#f,#o,#o]" string, which looks really ugly in some cases.
This patch changes it so that if erc-track-position-in-mode-line set to
t or whatever:
"---Mail [#e] ---" => "---Mail [#e]---"
and if it's 'after-modes
"(Emacs-Lisp)- [#e] --" => "(Emacs-Lisp)-[#e]--"
Nuttin' changes if it's set to 'before-modes.
Also, shouldn't the default setting be to show it in global-mode-string?
That's the Emacs standard, isn't it?
|
|
From: disumu <ds...@mu...> - 2005-03-01 14:01:48
|
Michael Olson <mw...@gn...> wrote: > Just wanted to let you know that (to the best of my knowledge) I > migrated all of the patches committed before 2005-01-19 to the 5.0 > release branch. I've tried to make my own fixes on the release branch first before merging them to CVS HEAD because it's much easier to test those fixes on a stable, working version. Knowing how this project works, I understand that it's somehow too much to ask other developers to do the same, so I've been applying changes from the development branch that also fix ERC 5.0 as the changes are added (for example, up until now I've been testing the non-ASCII fix and think it can be applied before the next bugfix release). But do we need a 5.0 CVS branch anymore at all if any and all changes made to the development branch are merged to it after it's been a while since they were added? If this is the way it's going to be, I don't see any reason for me to do the extra work anymore ;P -- disumu |
|
From: Michael O. <mw...@gn...> - 2005-03-01 05:51:22
|
Just wanted to let you know that (to the best of my knowledge) I migrated all of the patches committed before 2005-01-19 to the 5.0 release branch. Please let me know if you notice anything additional broken compared to the previous state of the 5.0 branch (or feel free to fix it, of course :^). =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: anime, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Michael O. <mw...@gn...> - 2005-02-28 19:41:53
|
Henrik Enberg <hen...@te...> writes: > Unfortunately, you committed the first, broken version. I posted a > fixed one in <87l...@ro...>. > > Anyways, here's the correct way against current CVS, so no need to > back out the previous commit. Sorry about that. The fix should be installed now. =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: anime, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Henrik E. <hen...@te...> - 2005-02-28 17:23:05
|
Michael Olson <mw...@gn...> writes: > Henrik Enberg <hen...@te...> writes: > >> Currently, erc-hide-list is only checked in the message handlers of >> a small subset[1] of all possible messages. It'd be nice to be able >> to hide any message without having to resort to erc-insert-this and >> funky regexps. >> >> The attached patch moves the check to erc-display-message and >> removes the checks from the handlers in erc-backend.el > > I've applied this to CVS head. Unfortunately, you committed the first, broken version. I posted a fixed one in <87l...@ro...>. Anyways, here's the correct way against current CVS, so no need to back out the previous commit. |
|
From: Michael O. <mw...@gn...> - 2005-02-28 03:08:17
|
I'd like to make a release of ERC 5.0.2 by Wednesday March 2. One feature in particular that I'd like to have in 5.0.2 is the fix for messages from different servers going into incorrect buffers. I changed `erc-version-string' in CVS head so that the text "(CVS)" is displayed next to the version number. If anyone objects, feel free to change/discuss it. =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: anime, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Michael O. <mw...@gn...> - 2005-02-28 02:08:25
|
Henrik Enberg <hen...@te...> writes: > Currently, erc-hide-list is only checked in the message handlers of > a small subset[1] of all possible messages. It'd be nice to be able > to hide any message without having to resort to erc-insert-this and > funky regexps. > > The attached patch moves the check to erc-display-message and > removes the checks from the handlers in erc-backend.el I've applied this to CVS head. =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: anime, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Henrik E. <hen...@te...> - 2005-02-14 09:59:45
|
Lawrence Mitchell <we...@gm...> writes: > Henrik Enberg wrote: > >> Currently, erc-hide-list is only checked in the message handlers of a >> small subset[1] of all possible messages. It'd be nice to be able to >> hide any message without having to resort to erc-insert-this and funky >> regexps. > >> The attached patch moves the check to erc-display-message and removes >> the checks from the handlers in erc-backend.el > >> [1] JOIN, KICK, MODE, NICK, PART, QUIT and TOPIC > > This looks fine to me, apart from the one comment below. > > [...] > >> See also `erc-format-message' and `erc-display-line'." >>+ (unless (and (arrayp parsed) > ^^^^^^^ > This ought to be `erc-response-p' I guess. The patch is still wrong, unfortunately. sometimes erc-display-message is legitimately called with a nil PARSED arg. A revised patch that handles this is attached. |
|
From: Lawrence M. <we...@gm...> - 2005-02-14 09:33:52
|
Henrik Enberg wrote:
> Currently, erc-hide-list is only checked in the message handlers of a
> small subset[1] of all possible messages. It'd be nice to be able to
> hide any message without having to resort to erc-insert-this and funky
> regexps.
> The attached patch moves the check to erc-display-message and removes
> the checks from the handlers in erc-backend.el
> [1] JOIN, KICK, MODE, NICK, PART, QUIT and TOPIC
This looks fine to me, apart from the one comment below.
[...]
> See also `erc-format-message' and `erc-display-line'."
>+ (unless (and (arrayp parsed)
^^^^^^^
This ought to be `erc-response-p' I guess.
--
Lawrence Mitchell <we...@gm...>
|
|
From: Henrik E. <hen...@te...> - 2005-02-13 23:02:52
|
Currently, erc-hide-list is only checked in the message handlers of a small subset[1] of all possible messages. It'd be nice to be able to hide any message without having to resort to erc-insert-this and funky regexps. The attached patch moves the check to erc-display-message and removes the checks from the handlers in erc-backend.el [1] JOIN, KICK, MODE, NICK, PART, QUIT and TOPIC |
|
From: Andreas S. <sc...@su...> - 2005-02-04 10:18:14
|
Michael Olson <mw...@gn...> writes: > +(defun erc-decode-parsed-server-response (parsed-response) > + "Decode a pre-parsed PARSED-RESPONSE before it can be handled. > + > +Decode `erc-response' acroding the car of it's `command-args' or if Typo: "according to the car of its `command-args'" > +that is not a channel, use the `erc-default-coding-system' to > +decoding." "use `erc-default-coding-system' for decoding" Andreas. --=20 Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux Products GmbH, 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: Lawrence M. <we...@gm...> - 2005-02-04 08:24:09
|
Michael Olson wrote: > Does anyone mind if I install this patch to CVS Head sometime this > weekend? It's the latest version from "It's me FKtPp ;)". I'm not > extremely familiar with ERC code internals, so I thought I'd ask > first. Looks reasonable to me, if there's no need for erc-decode-string-from-target in backend handlers (where they've been commented out), it's probably best to either remove them completely, or add a comment as to why they've been commented out. Lawrence -- Lawrence Mitchell <we...@gm...> |
|
From: Michael O. <mw...@gn...> - 2005-02-04 02:08:24
|
Does anyone mind if I install this patch to CVS Head sometime this weekend? It's the latest version from "It's me FKtPp ;)". I'm not extremely familiar with ERC code internals, so I thought I'd ask first. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /~ |\ | | | Interests: animé, Debian GNU/Linux, XHTML, wiki, Lisp |_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html |
|
From: Michael O. <mw...@gn...> - 2005-02-02 02:08:22
|
"It's me FKtPp ;)" <m_...@ya...> writes: > what should I do next? repack and post the most recent version of > the patch or something? Sounds right to me :^) . =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: It's me F. ;) <m_...@ya...> - 2005-02-01 05:07:44
|
hi, I've complete the process of assign the copyright of the patch to FSF, and recived a pdf copy of the assign paper. what should I do next? repack and post the most recent version of the patch or something? best regards FKtPp |
|
From: Jorgen S. <fo...@fo...> - 2005-01-21 16:02:57
|
Michael Olson <mw...@gn...> writes:
> Jorgen Schaefer <fo...@fo...> writes:
>
>> I noticed that recently, people are keeping a ChangeLog in CVS.
>>
>> Why?
Thanks for your reply!
> 1. Auxiliary tools like cvs2cl and our previous solution did a sloppy
> job, even with the options tweaked.
CVS problem, ok.
> 2. It's easier for those who follow the bleeding edge CVS source to
> see what has changed.
CVS problem, ok.
> 3. It makes life a lot easier for those who aspire to mirror the CVS
> tree using a different revision control system, say ... Arch.
How so? Every mirror to a different revision control system should
preserve the CVS commit log.
> 4. It eliminates uncertainty about what the exact format of log
> entries have to look like and allows for corrections to mistakes.
> This has the pleasant side effect of letting those who are just
> getting started with ERC development (like me) to feel more
> confident.
CVS problem, ok.
So the summary is: CVS sucks, hence we have to do it this way.
Thanks :-)
In the future, I think we should announce such changes to the
policy on the list, with a resoning on why we do it, so such
misunderstandings won't arise anymore...
Greetings,
-- Jorgen
=2D-=20
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: Michael O. <mw...@gn...> - 2005-01-21 00:32:32
|
Andreas Schwab <sc...@su...> writes: > Michael Olson <mw...@gn...> writes: > >> For example: >> >> $ tla register-archive http://www.mwolson.org/2005 > > unable to access URL: /2005/.listing > webdav error: 404 Not Found Sorry about that. I mistyped the location. That line should read: $ tla register-archive http://www.mwolson.org/archives/2005 =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-20 19:52:58
|
Michael Olson <mw...@gn...> writes: > Using Arch might make merging changes between the release_5_0_branch > and the Head easier, since the program that I use to translate CVS > commits to Arch determines "changesets" rather than just changes to > a single file. Working with changesets is usually easier compared > to working on a file-by-file basis. For example: $ tla register-archive http://www.mwolson.org/2005 ... $ tla get -A mw...@gn...--2005 erc--cvs--5.0 erc-5.0 ... $ cd erc-5.0 $ tla missing mw...@gn...--2005/erc--cvs-head--0 patch-5 patch-6 patch-7 This shows you that patches 5, 6, and 7 from my mirror of the CVS Head have not yet been applied to the 5.0 branch. =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-20 19:08:23
|
I've started an Arch mirror for ERC. This is not meant to supplant the official CVS repository. You don't have to use them if you don't want to. The CVS repository will (and should) stay current. Location: http://www.mwolson.org/archives/2005 Name: mw...@gn...--2005 Branches: erc--cvs--5.0: Follows release_5_0_branch erc--cvs-head--0: CVS Head These may be viewed and browsed online at http://www.mwolson.org/cgi-bin/archzoom/archzoom.cgi/mw...@gn...--2005/= erc?expand I maintain these branches by hand (for now), but I update fairly often. Using Arch might make merging changes between the release_5_0_branch and the Head easier, since the program that I use to translate CVS commits to Arch determines "changesets" rather than just changes to a single file. Working with changesets is usually easier compared to working on a file-by-file basis. See http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes for information on using Arch. Especially consult the "Normal editing cycle" and "Create a branch" sections if you are interested in using Arch to develop ERC. =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: Jorgen S. <fo...@fo...> - 2005-01-20 14:51:45
|
Brian Palmer <bp...@re...> writes:
> Jorgen Schaefer <fo...@fo...> writes:
>
>> The problem is that `erc-1' (former `erc') isn't "internal", but
>> actually useful for other parts or programs. I use it in my
>> .emacs, and other parts of erc use it as well.
>
> Yes, but it's not clear you should be using erc instead of erc-select
> :-) It used to be that erc-select was not callable from elisp, becaues
> it would always prompt the user for arguments. I moved all that into
> the interactive declaration, so it should be very usable when calling
> directly.
Why do we have two separate procedures?
Greetings,
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: Brian P. <bp...@re...> - 2005-01-20 14:41:08
|
Jorgen Schaefer <fo...@fo...> writes: > The problem is that `erc-1' (former `erc') isn't "internal", but > actually useful for other parts or programs. I use it in my > .emacs, and other parts of erc use it as well. Yes, but it's not clear you should be using erc instead of erc-select :-) It used to be that erc-select was not callable from elisp, becaues it would always prompt the user for arguments. I moved all that into the interactive declaration, so it should be very usable when calling directly. -- I'm awfully glad I'm a Beta, because I don't work so hard. |
|
From: Michael O. <mw...@gn...> - 2005-01-20 02:52:33
|
Jorgen Schaefer <fo...@fo...> writes:
> I noticed that recently, people are keeping a ChangeLog in CVS.
>
> Why?
1. Auxiliary tools like cvs2cl and our previous solution did a sloppy
job, even with the options tweaked.
2. It's easier for those who follow the bleeding edge CVS source to
see what has changed.
3. It makes life a lot easier for those who aspire to mirror the CVS
tree using a different revision control system, say ... Arch.
4. It eliminates uncertainty about what the exact format of log
entries have to look like and allows for corrections to mistakes.
This has the pleasant side effect of letting those who are just
getting started with ERC development (like me) to feel more
confident.
=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: Francis L. <fr...@wo...> - 2005-01-20 02:10:22
|
I wrote: > This proposed patch makes erc-button-face have priority over existing > faces when erc-button.el buttonizes an URL. I just committed this patch. Please let me know (here or in #emacs) if you experience any problems related to this change. -- Francis Litterio franl <at> world . std . com |
|
From: Jorgen S. <fo...@fo...> - 2005-01-20 01:28:02
|
Hi there.
I noticed that recently, people are keeping a ChangeLog in CVS.
Why?
We used to use cvs2cl to generate the ChangeLog from the CVS
messages. Keeping a separate ChangeLog file seems to duplicate
data for no obvious gain at all.
Since it's the worst possible case that some people don't add
entries to the ChangeLog, and some do, I think we should settle on
a policy for this.
1) I'm strongly against keeping duplicate information.
I.e. either ChangeLog or CVS commit messages die.
2) I'm strongly in favor of keeping revision information in the
revision control system, and not in a file separate from the
revision control system.
I.e. keep the CVS commit messages.
3) Of course, a ChangeLog is important for releases.
I.e. use cvs2cl for a release.
Greetings,
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
197 messages has been excluded from this view by a project administrator.
