Re: [Erc-help] smoke's TODO list

[Mario L. <ml...@ho...>]

sm...@wa... (Tijs van Bakel) writes:

> Ok here is my enormous list of bugs and ideas.
and here is a review, with done items marked.

> 
> erc-switchb:
> - An alternative to iswitchb-buffer for erc buffers only.  The
> following snippet shows the basic action, but the buffer names are too
> long, and I see no easy way to make iswitchb use shorter alternatives
> (iswitchb-read-buffer would return the abbreviated buffername, which
> has to be mapped back again; this is A possibility, but perhaps there
> are better alternatives?).  See also the next point about buffer
> names.
This is in cvs, and works, sort of. Only rpoblem is that the user currently
has to use iswitchb-default-keybindings, otherwise it doesnt work, and
I still have no idea why.

> Buffer names:
> - Buffer names could perhaps be abbreviated to "#emacs, #emacs<2>,
> #lisp, MisterX" to denote #emacs on 2 different servers, and a query
> to MisterX.  This would be useful both for switching and display in
> the mode-line.  I have not found a convincing method on how to exactly
> name the buffers, though.
Done. finished, working, rocking!
> 
> Buffer list:
> - There is now a list of buffers _per server_.  It seems better to
> have one global list for all buffers.  It would be nice to make this a
> property or alist, so that more data could be put in there.  Think
> about flags like "modified", "someone sent you a personal message
> there", ..
Don.e the function (erc-buffer-list) can be used to generate either
a list of all buffers on all servers, or all buffers related to a specific
process (server).

> Inconsistency in feedback of input text:
> - A message makes the entry prompt disappear, but for a /ME command it
> doesn't.  Should be easy to fix, but perhaps there's a reason for this
> behaviour?
antifuchs also reminded me of that today. Not done anything yet.

> Timestamps:
> - The code for adding of timestamps seems a bit messy.  I
> found this snippet repeated many times throughout the code:
> 
>   (if erc-timestamp-format
>       (format-time-string erc-timestamp-format
> 			  (current-time)) "")
> 
> This should obviously be taken into a function.  Perhaps it would be
> better to have a hook to reformat a line of text though?  Also, a
> timestamp is not prepended to messages sent by yourself, nor for
> server messages (topics &c.)  I think other irc clients have a
> timestamp-level value to select which messages should get a timestamp,
> and which shouldn't.
> [Note: I have done a bit of work on this already, but it doesn't
> support timestamp levels yet.  A generalization would be nice.]
right, its better than it was before though already...

> 
> Scrolling:
> - "M-x term" manages to keep the entire window in use, having the
> input line near the bottom of the window.  This seems to be
> implemented by having a _lot_ of (recenter (1- term-height)) calls all
> over term.el.  Not the most elegant method, but it is effective.
> Could a somewhat cleaner method be used for erc, or should I just add
> recenter calls everywhere where needed?
I think you have some local code for that?

> 
> Pop-up buffers:
> - On incoming messages, with auto-query enabled, the query pops up,
> and interrupts my typing.  It'd be nice to have these buffers buried
> by default (the mode-line change is enough).  Nice customization
> option -- seems I could hack this in somewhere.
> [Note: Fixed, by adding a "bury" option to erc-join-buffer.  It might
> be nice to rename erc-join-buffer to erc-new-buffer.]
done (by you)

> 
> Persistent buffers:
> - It would be nice to be able to save (C-x C-s) a buffer log, and
> continue with it later.  A message like ">> disconnected" could mark
> where one picked up again.  Something analogous like (desktop-read)
antifuchs has done some log/save related things today, I didnt see the patch
yet, so I have no idea if this is already covered in some way.

> Nick change tracking in queries:
> - Subject says it all :-)  It seems that MIRC and some other irc
> clients are capable of doing this, but I don't know the relevant
> commands to send to a server in order to be notified of nick changes.
> "Someone should research this"
yow, thats still a problem.
And I have no idea why you would sent to the server. If you are on the
same channels as the other guy, it is obviously no problem...

> Tracking channels [,#bug]:
> - The extra comma is an obvious bug.  It seems better (at least to me)
> to have a _list_ of buffers that are changed, instead of using a
> _string_ to store the changed buffers.  When updating the modeline,
> the list can be processed to produce the string, but the other way
> around seems to be cumbersome, the current method is prone to errors.
Still not fixed.

> Misc.:
> 
> - When quoting using "\C-RET", leading spaces should not be stripped
> (try quoting a lisp function for instance)
hmm, did you fix that. I didnt see that problem lately.

> 
> - Transform "/join elisp" into "/join #elisp".
Done (by you).
 
> - Mimick the /quote feature of TinyFugue.
I dont know what this means.

> - Give some feedback when signing off.
right, that would be useful...
> 
> - DCC (zenirc seems to support dcc get, and dcc chat for incoming
> chats) How would one interface with a subprocess in a compatible
> way?
Yow, dcc would be good, I read zenirc-dcc.el and it doesnt look to hard.
One thing I would like to acomplish differently is that I'd like to have
DCC as minor-mode for erc. zenirc currently implements a completely
new major mode, and this looks like duplication to me.

> 
> - Unset a topic
> 
> - A way to toggle "/" into some other character.  Sometimes one wants
> to type text starting with a "/" character.
really, it shouldnt be to hard, but do you really think people would use/need that?


-- 
CYa,
   Mario <ml...@de...>
Homepage(s): http://delysid.org | http://piss.at/

I think it's a new feature.  Don't tell anyone it was an accident.  :-)
         -- Larry Wall on s/foo/bar/eieio in <10...@jp...>