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: Jeremy Maitin-S. <jb...@at...> - 2004-02-02 22:37:34
|
The attached patch changes `erc-process-sentinel' to use `erc' rather than `erc-connect' when auto-reconnecting. This should eliminate a number of mostly minor bugs. I have tested it somewhat, and I do not believe it breaks anything. It also fixes a bug in `erc-get-buffer' (but I do not know if this bug is actually triggered anywhere) and makes a minor change elsewhere. |
|
From: Jeremy Maitin-S. <jb...@at...> - 2004-02-02 22:23:40
|
lawrence mitchell <we...@gm...> writes: > I tracked this problem down to a bug in > ERC-BUFFER-LIST-WITH-NICK. NICK wasn't being downcased, and > hence the GETHASH was returning nil. This should hopefully be > fixed in 1.622. I haven't spotted any other remnants of the > move away from a custom hash-table test, so hopefully there are > no more bugs like this. Great. -- Jeremy Maitin-Shepard |
|
From: lawrence m. <we...@gm...> - 2004-02-02 19:55:57
|
lawrence mitchell wrote: [...] > I haven't really looked at it yet. It seems to have be for > those people who JOIN after I'm in the channel, but that's only > a hunch. I'll try and look at it further tomorrow. I tracked this problem down to a bug in ERC-BUFFER-LIST-WITH-NICK. NICK wasn't being downcased, and hence the GETHASH was returning nil. This should hopefully be fixed in 1.622. I haven't spotted any other remnants of the move away from a custom hash-table test, so hopefully there are no more bugs like this. -- lawrence mitchell <we...@gm...> |
|
From: lawrence m. <we...@gm...> - 2004-02-02 00:11:06
|
Jeremy Maitin-Shepard wrote: > Do you have any additional information as to the circumstances in which > the QUIT message is displayed only in the server buffer? The buffers > member of the erc-server-user struct seems to be getting set properly, > I see at least some quit messages going to the channel buffers. I haven't really looked at it yet. It seems to have be for those people who JOIN after I'm in the channel, but that's only a hunch. I'll try and look at it further tomorrow. -- lawrence mitchell <we...@gm...> |
|
From: Jeremy Maitin-S. <jb...@at...> - 2004-02-01 23:23:11
|
Do you have any additional information as to the circumstances in which the QUIT message is displayed only in the server buffer? The buffers member of the erc-server-user struct seems to be getting set properly, I see at least some quit messages going to the channel buffers. -- Jeremy Maitin-Shepard |
|
From: lawrence m. <we...@gm...> - 2004-02-01 21:24:46
|
Due to one of the recent changes, QUIT messages from the server sometimes no longer appear in the current channel, instead showing up in one of the server buffers. I haven't looked at this properly, but I think it's probably bad interaction between ERC-BUFFER-LIST-WITH-NICK and ERC-SERVER-QUIT. If anyone has any ideas, I'd be grateful, otherwise I'll have a look at this tomorrow. Lawrence -- lawrence mitchell <we...@gm...> |
|
From: lawrence m. <we...@gm...> - 2004-01-30 22:05:08
|
Jeremy Maitin-Shepard wrote: > The patch is attached (I am not going to bother posting an explanation > here, since discussion is easier on #emacs anyway) forcer has committed this. If major breakages occur, you can revert to a pre-change version of erc using the symbolic tag: PRE_HASH_TABLE_CHANNEL_MEMBERS. lawrence (testing now) -- lawrence mitchell <we...@gm...> |
|
From: Jeremy Maitin-S. <jb...@at...> - 2004-01-27 23:28:31
|
Hello, The patch is attached (I am not going to bother posting an explanation here, since discussion is easier on #emacs anyway) |
|
From: Esben S. <exe...@on...> - 2004-01-21 21:45:01
|
I've been trying to get ctcp sound working for a long time without luck. I can't figure out where I can define the player it's supposed to use in erc-sound.el. -- b0ef |
|
From: lawrence m. <we...@gm...> - 2004-01-20 22:46:10
|
Johan Bockgård wrote: > Corrently pressing `undo' in an erc buffer scrmables the text. This > patch improves the situation. [...] I've now committed this, thanks. Holler if anything broke. -- lawrence mitchell <we...@gm...> |
|
From: Michael H. <mw...@py...> - 2004-01-16 16:56:25
|
On Friday, Jan 16, 2004, at 13:32 Europe/London, Michael Hudson wrote: > The condition-case in erc-process-input-line caused me considerable > confusion this morning: my erc-cmd- function was being called with the > right number of arguments but had a bug whereby it called another > function with the wrong number of arguments. This patch allows it to > crash (or enter the debugger) normally but preserves the nice error > message on > > /mycmd wrong number of arguments > > by parsing erc-cmd-MYCMD's arglist. > > I think this might break erc on older Emacsen that lack > help-function-arglist -- can erc-get-arglist be extended to > byte-compiled functions easily and portably? Let's try a version with more hope of working... Cheers, mwh |
|
From: Michael H. <mw...@py...> - 2004-01-16 13:34:31
|
The condition-case in erc-process-input-line caused me considerable confusion this morning: my erc-cmd- function was being called with the right number of arguments but had a bug whereby it called another function with the wrong number of arguments. This patch allows it to crash (or enter the debugger) normally but preserves the nice error message on /mycmd wrong number of arguments by parsing erc-cmd-MYCMD's arglist. I think this might break erc on older Emacsen that lack help-function-arglist -- can erc-get-arglist be extended to byte-compiled functions easily and portably? Anyone laughing at my elisp will be agreed with. Cheers, mwh |
|
From: lawrence m. <we...@gm...> - 2004-01-14 17:44:57
|
All over erc, I see stuff like:
(let ((ob (current-buffer))
(buffer (process-buffer buffer)))
(when buffer
(set-buffer buffer)
(do-stuff-in buffer)
...
(set-buffer ob)))
This has a few problems. It seems rather low level, it would be
nicer to have some kind of macrology to wrap the whole thing up.
It's not very safe, in the case of an error, we might well be
left in BUFFER, rather than back in OB.
What do people think of installing something like this:
(defmacro with-existing-buffer (buffer &rest body)
"Execute the forms BODY in BUFFER if it exists.
See also `with-current-buffer'."
(let ((tmp (make-symbol "TMP-BUF")))
`(let ((,tmp ,buffer))
(when (and ,tmp
(bufferp ,tmp))
(with-current-buffer ,tmp
,@body)))))
--
lawrence mitchell <we...@gm...>
|
|
From: <boj...@dd...> - 2004-01-14 08:50:10
|
Corrently pressing `undo' in an erc buffer scrmables the text. This
patch improves the situation.
Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.607
diff -u -r1.607 erc.el
--- erc.el 12 Jan 2004 20:18:24 -0000 1.607
+++ erc.el 14 Jan 2004 08:32:18 -0000
@@ -2405,35 +2405,69 @@
(when string
(save-excursion
(set-buffer (or buffer (process-buffer erc-process)))
- (let ((insert-position (or (marker-position erc-insert-marker)
- (point-max)))
- (string (erc-interpret-controls string))
- (buffer-undo-list t)
- (inhibit-read-only t))
- (unless (string-match "\n$" string)
- (setq string (concat string "\n"))
- (when (erc-string-invisible-p string)
- (erc-put-text-properties 0 (length string) string
- '(invisible intangible))))
- (erc-log (concat "erc-display-line: " string
+ (let ((undo-shift 0))
+ (let ((insert-position (or (marker-position erc-insert-marker)
+ (point-max)))
+ (string (erc-interpret-controls string))
+ (buffer-undo-list t)
+ (inhibit-read-only t))
+ (unless (string-match "\n$" string)
+ (setq string (concat string "\n"))
+ (when (erc-string-invisible-p string)
+ (erc-put-text-properties 0 (length string) string
+ '(invisible intangible))))
+ (erc-log (concat "erc-display-line: " string
(format "(%S)" string) " in buffer "
(format "%s" buffer)))
- (setq erc-insert-this t)
- (run-hook-with-args 'erc-insert-pre-hook string)
- (if (null erc-insert-this)
- ;; Leave erc-insert-this set to t as much as possible. Fran
- ;; Litterio <franl> has seen erc-insert-this set to nil while
- ;; erc-send-pre-hook is running, which should never happen. This
- ;; may cure it.
- (setq erc-insert-this t)
- (save-excursion ;; to restore point in the new buffer
- (goto-char insert-position)
- (insert-before-markers string)
- ;; run insertion hook, with point at restored location
- (save-restriction
- (narrow-to-region insert-position (point))
- (run-hooks 'erc-insert-modify-hook)
- (run-hooks 'erc-insert-post-hook))))))))
+ (setq erc-insert-this t)
+ (run-hook-with-args 'erc-insert-pre-hook string)
+ (if (null erc-insert-this)
+ ;; Leave erc-insert-this set to t as much as possible. Fran
+ ;; Litterio <franl> has seen erc-insert-this set to nil while
+ ;; erc-send-pre-hook is running, which should never happen. This
+ ;; may cure it.
+ (setq erc-insert-this t)
+ (save-excursion ;; to restore point in the new buffer
+ (goto-char insert-position)
+ (insert-before-markers string)
+ ;; run insertion hook, with point at restored location
+ (save-restriction
+ (narrow-to-region insert-position (point))
+ (run-hooks 'erc-insert-modify-hook)
+ (run-hooks 'erc-insert-post-hook)
+ (setq undo-shift (- (point-max) insert-position))))))
+ (erc-update-undo-list undo-shift)))))
+
+(defun erc-update-undo-list (shift)
+ ;; shift positions in buffer-undo-list on output
+ (setq buffer-undo-list
+ (mapcar
+ (lambda (e)
+ (cond ( (null e) ; `nil'
+ nil)
+ ( (numberp e) ; `POSITION'
+ (+ e shift))
+ ( (consp e)
+ (let ((car (car e)))
+ (cond ( (eq t car)) ; `(t HIGH . LOW)'
+ ( (eq nil car) ; `(nil PROPERTY VALUE BEG . END)'
+ (let ((cons (nthcdr 3 e)))
+ (incf (car cons) shift)
+ (incf (cdr cons) shift)))
+ ( (numberp car) ; `(BEG . END)'
+ (incf (car e) shift)
+ (incf (cdr e) shift))
+ ;; Is this correct? b-u-l should contain
+ ;; the actual markers.
+ ;; ( (markerp car) ; `(MARKER . ADJUSTMENT)'
+ ;; (and (marker-position car)
+ ;; (incf (marker-position car) shift)))
+ ( (stringp car) ; `(TEXT . POSITION)'
+ (if (> (cdr e) 0)
+ (incf (cdr e) shift)
+ (decf (cdr e) shift)))))
+ e)))
+ buffer-undo-list)))
(defvar erc-valid-nick-regexp "[]a-zA-Z^[;\\`_{}|][]^[;\\`_{}|a-zA-Z0-9-]*"
"Regexp which matches all legal characters in a IRC nickname.")
@@ -3866,6 +3900,7 @@
;; the prompt.
(when (or (not pos) (<= (point) pos))
(forward-char l))
+ (setq buffer-undo-list nil) ; flush undos
(set-buffer ob))))
;; interactive operations
|
|
From: lawrence m. <we...@gm...> - 2004-01-12 20:02:06
|
Brian Palmer wrote: > I just checked out the latest erc from sf.net, but I had problems > joining channels. Looks like member-ignore-case is being used in > erc-cmd-JOIN instead of erc-member-ignore-case. (I'm not sure that the > erc-member-ignore-case rules are entirely correct there; but there > needs to be something done, since xemacs does not have > member-ignore-case) Committed, thanks. -- lawrence mitchell <we...@gm...> |
|
From: Brian P. <bp...@re...> - 2004-01-12 19:55:15
|
I just checked out the latest erc from sf.net, but I had problems joining channels. Looks like member-ignore-case is being used in erc-cmd-JOIN instead of erc-member-ignore-case. (I'm not sure that the erc-member-ignore-case rules are entirely correct there; but there needs to be something done, since xemacs does not have member-ignore-case) Index: erc.el =================================================================== RCS file: /cvsroot/erc/erc/erc.el,v retrieving revision 1.602 diff -r1.602 erc.el 2834c2834 < (if (member-ignore-case chnl joined-channels) --- > (if (erc-member-ignore-case chnl joined-channels) -- I'm awfully glad I'm a Beta, because I don't work so hard. |
|
From: Jeremy Maitin-S. <jb...@at...> - 2003-12-24 23:07:15
|
Jeremy Maitin-Shepard <jb...@at...> writes: > [snip] > I will prototype some of these ideas. Actually, after considering it, I decided that the advantage of being able to setq `erc-settings' in a convenient way, even before loading erc, outweighs any advantage of using a cl struct or hash table. -- Jeremy Maitin-Shepard |
|
From: Jeremy Maitin-S. <jb...@at...> - 2003-12-24 22:20:28
|
lawrence mitchell <we...@gm...> writes: > Jeremy Maitin-Shepard wrote: > [...] > This makes more sense, I suppose, though, I like the original > version in a way, since CHANNEL is explicitly tied to NETWORK, > whereas with your format it isn't. > How about (VAR VALUE (NETWORK CHANNEL)) ? Well, the advantage to (VAR VALUE NETWORK CHANNEL) is that (caddr '(VAR VALUE)) is nil (i.e. no special handling needing. Also, if you wanted to specify just a network, would it be (VAR VALUE NETWORK) or (VAR VALUE (NETWORK)) ? (Both of these would require special handling, although with accessors it would be a moot point. In any case, if hash tables are used, this structure would not exist. >> [snip] >> Using a hash table to store the settings (instead of a list) would >> greatly simplify the definitions; but it is not clear that a >> sufficient number of settings will be stored in this system that a >> hash table would be more efficient. > Hash tables are not necessarily less efficient than lists. And, > if as you say, it would increase code simplicity, I think it > might be preferable to use them (especially since we don't > support emacsen without hash tables). I do not know exactly the overhead of using a hash table, but the info documentation specifies that a list with a few tens of elements may be faster than a hash table. However, because `erc-settings' is not a simple alist, and the code to manipulate it is rather complicated, it may be that a hash table is more efficient. As far as the code being simpler, it would only affect the code of the accessor functions, and so that is only a minor point. A significant disadvantage with using a hash table, however, is that users would need to have a bunch of `erc-put-setting' commands in their init files, rather than a (setq erc-settings ...) command (and the setq command would be a significantly faster than the hash table commands). >> [snip] >> ; car -> var >> ; cadr -> value >> ; caddr -> network >> ; cadddr -> target > ick ick ick :), I'd suggest defaliasing some functions, all in > the name of data transparancy. > (defalias 'erc-set-var 'car), etc... > Alternately, in the looping functions, you could use LOOP's > destructuring capabilities: > (loop for (var value network target) on erc-settings do ...) > OTOH, you may not be a fan of LOOP :). > I wonder also if your approach would lend itself to SETFable > functions. > e.g. (setf (erc-settings-get (foo bar "baz")) '(...)) When I first wrote the accessors, I used a slightly different interface, where `erc-setting-get' returned the list of (VAR VALUE NETWORK TARGET), and I provided setf-able macros to extract the components. But then I changed the interface to be compatible with a possible hash table interface. With the current interface, the user has no need for the setf-able macros, so I eliminated them. If we decide that 1) we don't want to use hash tables 2) it is better for `erc-get-setting' to return the list of (VAR VALUE NETWORK TARGET) rather than just VALUE, then I could re-add these macros. Another idea would be to use a cl struct vector as the entry in `erc-settings'. That might be the nicest technique if we want there to be more of an accessor interface. I will prototype some of these ideas. -- Jeremy Maitin-Shepard |
|
From: lawrence m. <we...@gm...> - 2003-12-24 16:54:51
|
Jeremy Maitin-Shepard wrote: [...] > Refer to the code in the attached file. Note that I changed the format > of `erc-settings' to something that is both easier for the accessor > functions to deal with and also should be easier for users to deal > with. Specifically, the old format was: > (VAR nil VALUE) ; applies to all networks > (VAR NETWORK VALUE) ; applies only to NETWORK > (VAR (NETWORK CHANNEL) VALUE) ; applies only to CHANNEL on NETWORK > The new accessor functions use this format: > (VAR VALUE) ; applies to all networks > (VAR VALUE NETWORK) ; applies only to NETWORK > (VAR VALUE NETWORK CHANNEL) ; applies only to CHANNEL on NETWORK This makes more sense, I suppose, though, I like the original version in a way, since CHANNEL is explicitly tied to NETWORK, whereas with your format it isn't. How about (VAR VALUE (NETWORK CHANNEL)) ? > You will notice that the definitions of the accessor functions are > rather complicated, especially `erc-get-setting'; this is because it is > necessary to handle a large number of specific cases separately, and I > do not believe there is any elegant way of doing it. Using a hash > table to store the settings (instead of a list) would greatly simplify > the definitions; but it is not clear that a sufficient number of > settings will be stored in this system that a hash table would be more > efficient. Hash tables are not necessarily less efficient than lists. And, if as you say, it would increase code simplicity, I think it might be preferable to use them (especially since we don't support emacsen without hash tables). > I also use a case-insensitive string to specify the network rather than > a symbol. I believe this is a better way of doing things. > Anyway, next on my list of stuff to tackle is `erc-macs.el'. Perhaps > before integrating it `victim' should be replaced with `member', or > specifically, `erc-victims' changed to `erc-global-members' and > `erc-channel-victims' changed to `erc-channel-members'. Conveniently, > the existing code uses the unqualified name `channel-members', and so > there is no conflict. > ; car -> var > ; cadr -> value > ; caddr -> network > ; cadddr -> target ick ick ick :), I'd suggest defaliasing some functions, all in the name of data transparancy. (defalias 'erc-set-var 'car), etc... Alternately, in the looping functions, you could use LOOP's destructuring capabilities: (loop for (var value network target) on erc-settings do ...) OTOH, you may not be a fan of LOOP :). I wonder also if your approach would lend itself to SETFable functions. e.g. (setf (erc-settings-get (foo bar "baz")) '(...)) Which would be nice. -- lawrence mitchell <we...@gm...> |
|
From: Jeremy Maitin-S. <jb...@at...> - 2003-12-24 11:48:48
|
Hello, Since I believe ERC automatically sends a QUIT command to servers when the server buffer is killed, the query from `save-buffers-kill-emacs' when a server connection is still open doesn't seem particularly useful, and is somewhat annoying. The attached patch adds a defcustom variable `erc-process-query-on-exit'. This variable is used by `erc-connect' in a call to `set-process-query-on-exit-flag'. |
|
From: Jeremy Maitin-S. <jb...@at...> - 2003-12-24 11:12:56
|
Hello, Noticing the comment in erc-nets.el, the in-progress `scoped' setting system (`erc-settings') seemed to be a good idea, so I replaced `erc-get' with accessor functions that work. Refer to the code in the attached file. Note that I changed the format of `erc-settings' to something that is both easier for the accessor functions to deal with and also should be easier for users to deal with. Specifically, the old format was: (VAR nil VALUE) ; applies to all networks (VAR NETWORK VALUE) ; applies only to NETWORK (VAR (NETWORK CHANNEL) VALUE) ; applies only to CHANNEL on NETWORK The new accessor functions use this format: (VAR VALUE) ; applies to all networks (VAR VALUE NETWORK) ; applies only to NETWORK (VAR VALUE NETWORK CHANNEL) ; applies only to CHANNEL on NETWORK You will notice that the definitions of the accessor functions are rather complicated, especially `erc-get-setting'; this is because it is necessary to handle a large number of specific cases separately, and I do not believe there is any elegant way of doing it. Using a hash table to store the settings (instead of a list) would greatly simplify the definitions; but it is not clear that a sufficient number of settings will be stored in this system that a hash table would be more efficient. I also use a case-insensitive string to specify the network rather than a symbol. I believe this is a better way of doing things. Anyway, next on my list of stuff to tackle is `erc-macs.el'. Perhaps before integrating it `victim' should be replaced with `member', or specifically, `erc-victims' changed to `erc-global-members' and `erc-channel-victims' changed to `erc-channel-members'. Conveniently, the existing code uses the unqualified name `channel-members', and so there is no conflict. |
|
From: Alex S. <al...@em...> - 2003-12-07 12:44:29
|
lawrence mitchell <we...@gm...> writes: > It's evil, since it relies on let-bound > variables propagating down the call stack Well, this is one of the features of dynamic binding. We might as well use it. :) If you are concerned, use a defvar for this piece of code. But notice that we do this in other places as well: Read the doc string of erc-send-pre-hook to see that we actually accounce it to users! Is this doubleplusungood? :) (Also note that I faintly remember being the author of said thing myself, haha.) Alex. -- .O. http://www.emacswiki.org/alex/ ..O Schroeder's first law: OOO The coffee at the office shall taste terrible. |
|
From: lawrence m. <we...@gm...> - 2003-12-06 23:43:38
|
What do people think of factoring out some of the code from
erc-send-current-line into a new function. This allows us to
insert things in an erc buffer correctly, without having to call
erc-send-current-line. Particularly handy for things like
erc-cmd-SAY. This patch is a first stab at it, just pulling out
the (lambda (line) ...) from erc-send-current-line into a
separate function. It's evil, since it relies on let-bound
variables propagating down the call stack, and they may not
always be bound, but it's late, and I haven't looked at it
properly.
Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.586
diff -u -r1.586 erc.el
--- erc.el 6 Dec 2003 22:43:29 -0000 1.586
+++ erc.el 6 Dec 2003 23:40:11 -0000
@@ -2450,7 +2450,8 @@
multiple lines of text."
(if (string-match "^\\s-*$" line)
nil
- (erc-process-input-line line nil t)))
+ (erc-process-input-line line nil t)
+ (erc-insert-line line t)))
(put 'erc-cmd-SAY 'do-not-parse-args t)
(defun erc-cmd-SET (line)
@@ -5777,44 +5778,7 @@
(when erc-show-my-nick
(erc-put-text-property 0 (length nickname) 'face
'erc-nick-default-face nickname))
- (mapc
- (lambda (line)
- (unless (string-match "^\\s-*\n*$" line)
- (if (null erc-insert-this)
- ;; Leave erc-insert-this set to t as much as possible.
- ;; Fran Litterio <franl> has seen erc-insert-this set to
- ;; nil while erc-send-pre-hook is running, which should
- ;; never happen. This may cure it.
- (setq erc-insert-this t)
- (let ((insert-position (point)))
- (if (and (not multiline-p)
- (char-equal (aref line 0) ?/)) ; is it a non-pasted command?
- (if (not erc-hide-prompt)
- (erc-display-prompt nil nil (erc-command-indicator)
- (and (erc-command-indicator)
- 'erc-command-indicator-face)))
- (insert ; ok, it's a privmsg.
- (if erc-show-my-nick
- (concat "<" nickname "> ")
- "> ")))
- (when (string-match "[\n]+$" line) ; remove the \ns at the end.
- (setq line (substring line 0 (match-beginning 0))))
- (erc-put-text-property 0 (length line)
- 'face 'erc-input-face line)
- (insert (erc-interpret-controls line))
- (goto-char (point-max))
- (open-line 1)
- (goto-char (point-max))
- (set-marker (process-mark erc-process) (point))
- (set-marker erc-insert-marker (point))
- (save-excursion
- (save-match-data
- (save-restriction
- (narrow-to-region insert-position (point-max))
- (run-hook-with-args 'erc-send-modify-hook)
- (run-hook-with-args 'erc-send-post-hook))))))
- (erc-process-input-line (concat line "\n") t multiline-p)))
- lines)))
+ (mapc #'erc-insert-line lines)))
;; Go to (point-max), but only if the command left an ERC buffer as the
;; current buffer.
(if (eq major-mode 'erc-mode)
@@ -5827,6 +5791,44 @@
(erc-display-prompt)
(set-buffer-modified-p buffer-modified))
(run-hook-with-args 'erc-send-completed-hook str)))))))
+
+(defun erc-insert-line (line &optional dont-send)
+ (unless (string-match "^\\s-*\n*$" line)
+ (if (null erc-insert-this)
+ ;; Leave erc-insert-this set to t as much as possible.
+ ;; Fran Litterio <franl> has seen erc-insert-this set to
+ ;; nil while erc-send-pre-hook is running, which should
+ ;; never happen. This may cure it.
+ (setq erc-insert-this t)
+ (let ((insert-position (point)))
+ (if (and (not multiline-p)
+ (char-equal (aref line 0) ?/)) ; is it a non-pasted command?
+ (if (not erc-hide-prompt)
+ (erc-display-prompt nil nil (erc-command-indicator)
+ (and (erc-command-indicator)
+ 'erc-command-indicator-face)))
+ (insert ; ok, it's a privmsg.
+ (if erc-show-my-nick
+ (concat "<" nickname "> ")
+ "> ")))
+ (when (string-match "[\n]+$" line) ; remove the \ns at the end.
+ (setq line (substring line 0 (match-beginning 0))))
+ (erc-put-text-property 0 (length line)
+ 'face 'erc-input-face line)
+ (insert (erc-interpret-controls line))
+ (goto-char (point-max))
+ (open-line 1)
+ (goto-char (point-max))
+ (set-marker (process-mark erc-process) (point))
+ (set-marker erc-insert-marker (point))
+ (save-excursion
+ (save-match-data
+ (save-restriction
+ (narrow-to-region insert-position (point-max))
+ (run-hook-with-args 'erc-send-modify-hook)
+ (run-hook-with-args 'erc-send-post-hook))))))
+ (or dont-send
+ (erc-process-input-line (concat line "\n") t multiline-p))))
(defun erc-extract-command-from-line (line)
"Extract command and args from the input LINE.
--
lawrence mitchell <we...@gm...>
|
|
From: lawrence m. <we...@gm...> - 2003-12-03 17:37:17
|
David Edmondson wrote: > * ml...@de... [20031203T170837]: >> Cool, I like this. But I am quite in a hurry right now, does anyone >> want to commit it? > I'd be happy for that to happen, though there are still loose ends. I can commit it at some point later this evening (probably), depending on a variety of factors probably outside of my control :). Also, a defcustom needs to be added to erc.el for erc-update-mode-line-hook. I know you've used erc-update-mode-line-hooks in your patch, but hook variables are usually singular, at least, all the ERC ones are. This would be something like: (defcustom erc-update-mode-line-hook nil "Hook run when ..." :group 'erc-hooks :type 'hook) erc-tab.el needs a (provide 'erc-tab.el) line. Check it with M-x checkdoc RET, that should pick up any errors. The tooltips do work, as well as multiline tooltips work in emacs (which isn't very well :). >> BTW, there is a elisp library in existance with implements a generic >> tabs-mode, I fogot the name. dme, did you look at the posibility of >> reusing that library, or do you perhaps already do this? This would be David Ponce's tabbar.el, I don't think it would be that easy to hook into this, since it implements tabs on a far more generaly level, rather than erc-tab, which is very specific, and consequently doesn't need that much code. > This is something that I didn't know about - I'll go look. I can't really do any debugging of this (the above mentioned problem) at the moment, as I'm rather overwhelmed with projects, however, I'll have a look at it some time next week. -- lawrence mitchell <we...@gm...> |
|
From: <dm...@dm...> - 2003-12-03 17:16:26
|
* ml...@de... [20031203T170837]: > Cool, I like this. But I am quite in a hurry right now, does anyone > want to commit it? I'd be happy for that to happen, though there are still loose ends. > BTW, there is a elisp library in existance with implements a generic > tabs-mode, I fogot the name. dme, did you look at the posibility of > reusing that library, or do you perhaps already do this? This is something that I didn't know about - I'll go look. dme. |
197 messages has been excluded from this view by a project administrator.
