erc-help — Archive of problems, bugs, features, news

[Erc-help] Dealing with blank lines

[Brian P. <bp...@re...>]

I believe that the current behaviour dealing with sending whitespace
only lines is broken when dealing with sending input that contains
newlines. This has been fairly embarrassing in the past when pasting
code into irc, for example, and I know it's struck some other people
:-)

I'm proposing the following patch, which will change the behaviour to
allow switching between sending no whitespace-only lines, sending only
whitespace-only lines that are not the beginning or ending, and
sending every whitespace-only line, with it defaulting to the second
case. (I suppose ideally it would collapse together multiple leading
or trailing lines, but the code does not currently do so ). 

I'm asking for opinions as to whether all three of those options
should be present, whether more should be added, and if so, what the
default would be. (I don't foresee a tremendous use for the 'middle
behaviour myself (I plan on setting it to nil and keeping it there),
but some others on the channel thought it'd be useful, and be a
reasonable default).

Depending on feedback, I'll probably commit this tomorrow. 

Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.702
diff -r1.702 erc.el
157,160c157,167
< (defcustom erc-send-whitespace-lines nil
<   "If set to non-nil, send lines consisting of only whitespace."
<   :group 'erc
<   :type 'boolean)
---
> (defcustom erc-send-whitespace-lines 'middle
>   "Set whether erc will send user lines that are completely whitespace. 
> If t, send all whitespace-only lines; if 'middle, only
> send non leading/terminal whitespace-only lines. If nil, skip over
> every whitespace-only line. Lines that are not sent will be warned
> about, if erc-warn-about-blank-lines is set. "
>   :group 'erc
>   :type '(choice (const :tag "Always send whitespace lines" t)
> 		 (const :tag "Send whitespace lines in the middle of a message" middle)
> 		 (const :tag "Never send all-whitespace lines" nil)))
> 
5762a5770
> 
5768,5781c5776,5795
<   (cond
<    ;; Ignore empty input
<    ((if erc-send-whitespace-lines
<         (string= input "")
<       (string-match "\\`[ \t\r\f\n]*\\'" input))
<     (when erc-warn-about-blank-lines
<       (message "Blank line - ignoring...")
<       (beep))
<     nil)
<    (t
<     (let ((str input))
<       (setq erc-send-this t)
<       (setq erc-insert-this t)
<       (run-hook-with-args 'erc-send-pre-hook input)
---
>   (let ((str input)
> 	(rv nil))
>     (setq erc-send-this t)
>     (setq erc-insert-this t)
>     (run-hook-with-args 'erc-send-pre-hook input)
>     
>     (let* ((lines (split-string str "\n"))
> 	   (interpet-commands (= (length lines) 1)))
>       (loop for (line next-line) on lines for not-first-line = nil then t
> 	if (or (not (string-match "\\`[ \t\r\f\n]*\\'" line))
> 	       (eq t erc-send-whitespace-lines)
> 	       (and (eq 'middle erc-send-whitespace-lines) not-first-line (not (null next-line))))
> 	do (erc-send-single-line line interpet-commands erc-send-this erc-insert-this)
> 	   (setq rv t)
> 	else 
> 	if erc-warn-about-blank-lines 
> 	do (message "Blank line - ignoring...") 
> 	   (beep)
> 	finally return rv))))
> 
5783,5795d5796
<       (if (string-match "\n" str)
< 	  (mapc
< 	   (lambda (line)
< 	     (erc-send-single-line line
< 				   nil
< 				   erc-send-this
< 				   erc-insert-this))
< 	   (split-string str "\n"))
< 	(erc-send-single-line str
< 			      t
< 			      erc-send-this
< 			      erc-insert-this))
<       t))))


-- 
I'm awfully glad I'm a Beta, because I don't work so hard.

[Erc-help] handling "unknown service irdc" in erc-select

[<kyl...@us...>]

Hi,

if there is no service entry for ircd on the platform, but I still accept
"irdc" as the port in M-x erc-select, the connection attempt will abort
with an invalid-argument error.

It would be nicer to handle the error by asking the user to provide a port
number.  This is an attempt to do that:

Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.702
diff -u -r1.702 erc.el
--- erc.el        5 Oct 2004 16:22:12 -0000        1.702
+++ erc.el        12 Oct 2004 19:46:54 -0000
@@ -2270,12 +2270,23 @@
                              ?S erc-session-server
                              ?p erc-session-port)))
     (message "%s" msg)
-    (setq erc-process
-          (funcall erc-connect-function
-                   (format "erc-%s-%s" erc-session-server erc-session-port)
-                   (current-buffer)
-                   erc-session-server
-                   erc-session-port))
+    (while (null erc-process)
+      (condition-case err
+          (progn
+            (setq erc-process
+                  (funcall erc-connect-function
+                           (format "erc-%s-%s" erc-session-server erc-session-port)
+                           (current-buffer)
+                           erc-session-server
+                           erc-session-port)))
+        ;; handle the unknow service error:
+        (invalid-argument
+         (if (not (equal "Unknown service" (cadr err)))
+             (error (car err) (cdr err))
+           (setq erc-session-port
+                 (read-from-minibuffer
+                  (format "Unknown service %s, please enter IRC port number: "
+                          erc-session-port)))))))
     (message "%s...done" msg))
   (set-process-sentinel erc-process 'erc-process-sentinel)
   (set-process-filter erc-process 'erc-process-filter)


-- René

[Erc-help] Re: My second time, to try to fix the non-ascii nick and topic problem

[Andrey S. <an...@in...>]

28 Sep 2004 20:18:22 +0800, It's me FKtPp ;) wrote:

> This is the patch.

[...]
  Best! It's really fixed all problem for incorrect showing russian
nicks.

Big Thanks.

Regards,
Andrey.

[Erc-help] Re: My second time, to try to fix the non-ascii nick and topic problem

[Cheng G. <che...@gm...>]

I just applied the patch, and found it did work like a charm. Now
Chinese in channel and nick name can be displayed without problem.

I suggest this patch be committed.

CG

-- 
No God blessing me
No Dog barking at me
Gonna adopt a Dog
Name it God
Get blessed and barked at

[Erc-help] My second time, to try to fix the non-ascii nick and topic problem

[It's me F. ;) <m_...@16...>]

This is the patch.

sorry for take some erc-* namespace.

===================================================================
RCS file: E:\FKtPp\cvsroot/emacs/erc/erc-backend.el,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- erc-backend.el	25 Sep 2004 13:03:24 -0000	1.1.1.2
+++ erc-backend.el	25 Sep 2004 13:36:35 -0000	1.2
@@ -151,8 +151,45 @@
     (setf (erc-response.command-args msg)
           (nreverse (erc-response.command-args msg)))
 
+    (erc-decode-parsed-server-response msg)
+
     (erc-handle-parsed-server-response proc msg)))))
 
+(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
+that is not a channel, use the `erc-default-coding-system' to
+decoding."
+  (let* ((args (erc-response.command-args parsed-response))
+	 (first-arg (car args))
+	 (matchp (string-match "^[#&].*" first-arg))
+	 (decode-target (if matchp
+			    (erc-decode-string-from-target first-arg nil)
+			  nil))
+	 (decoded-args ()))
+    (setf (erc-response.unparsed parsed-response)
+	  (erc-decode-string-from-target
+	   (erc-response.unparsed parsed-response)
+	   decode-target))
+    (setf (erc-response.sender parsed-response)
+	  (erc-decode-string-from-target
+	   (erc-response.sender parsed-response)
+	   decode-target))
+    (setf (erc-response.command parsed-response)
+	  (erc-decode-string-from-target
+	   (erc-response.command parsed-response)
+	   decode-target))
+    (dolist (arg args nil)
+      (add-to-list 'decoded-args
+		   (erc-decode-string-from-target arg decode-target)
+		   t))
+    (setf (erc-response.command-args parsed-response) decoded-args)
+    (setf (erc-response.contents parsed-response)
+	  (erc-decode-string-from-target
+	   (erc-response.contents parsed-response)
+	   decode-target))))
+
 ;; (defun erc-parse-server-response (process response)
 ;;   "Parse a server PROCESS's IRC RESPONSE."
 ;;   ;; FIXME: this function doesn't do the same as our original
@@ -604,8 +641,9 @@
 	     (privp (erc-current-nick-p tgt))
 	     s buffer
 	     fnick
-	     (msg (erc-decode-string-from-target msg
-						 (if privp sender-spec tgt))))
+	     ;; (msg (erc-decode-string-from-target msg
+;; 						 (if privp sender-spec tgt)))
+	     )
 	(setf (erc-response.contents parsed) msg)
 	(setq buffer (erc-get-buffer (if privp nick tgt) proc))
 	(when buffer
@@ -667,8 +705,9 @@
 (define-erc-response-handler (TOPIC)
   nil nil
   (let* ((ch (first (erc-response.command-args parsed)))
-         (topic (erc-trim-string (erc-decode-string-from-target
-                                  (erc-response.contents parsed) ch)))
+         (topic (erc-trim-string ;; (erc-decode-string-from-target
+                                  (erc-response.contents parsed) ;; ch)
+		))
          (time (format-time-string "%T %m/%d/%y" (current-time))))
     (multiple-value-bind (nick login host)
         (erc-parse-user (erc-response.sender parsed))

[Erc-help] away bug?

[It's me F. ;) <m_...@16...>]

If somebody set the erc-nick to a nickname list. And change his status
from away to back. The nick name auto-change will fail. so I changed
the function.

===================================================================
RCS file: E:\FKtPp\cvsroot/emacs/erc/erc.el,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- erc.el	25 Sep 2004 13:03:29 -0000	1.1.1.2
+++ erc.el	28 Sep 2004 10:34:31 -0000	1.2
@@ -5184,7 +5184,7 @@
 			   erc-away-nickname away-p))
 	  (erc-cmd-NICK (if away-p
 			    erc-away-nickname
-			  erc-nick)))
+			  (if (consp erc-nick) (car erc-nick) erc-nick))))
 	(cond
 	 (away-p
 	  (erc-with-all-buffers-of-server proc nil

Re: [Erc-help] Newbie questions

[Alex S. <al...@em...>]

Pascal J.Bourguignon <pj...@in...> writes:

> If I configure erc-auto-query to 'window, it opens correctly a new
> window to display the answer, but if this window is buried, later
> answers don't make it pop up again.

Yeah, I use erc-track-mode for activity...

Alex
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: [Erc-help] Newbie questions

[Pascal J.B. <pj...@in...>]

Jorgen Schaefer writes:
> > - the answers to /msg commands given in a #channel buffer go to the
> >   server buffer.  How can one get them in the #channel buffer where
> >   the /msg command was given?
> 
> You can customize erc-auto-query to make it open a new window when
> someone sends you a message. ERC does not do the bookkeeping to
> determine if and where a message was sent to someone so it can
> find out where it should display a reply. But actually, the reply
> should be displayed in the current window (or last active erc
> window). Does it really show up only in the server buffer?

Yes, in the server buffer.  Not in the active erc window.

If I configure erc-auto-query to 'window, it opens correctly a new
window to display the answer, but if this window is buried, later
answers don't make it pop up again.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

[Erc-help] Re: Newbie questions

[Pascal J.B. <pj...@in...>]

J. David Boyd writes:
> > > > - how to erase (/clean) a channel buffer?  erase-buffer complains for
> > > >   read-only text. For now, the only solution I have is /leave and
> > > >   /join #channel. (And I mean really removing all the buffer contents,
> > > >   not jumping down!)
> > After 0 kbd macro iterations: byte-code: Text is read-only: #<buffer #lisp>
> 
> Ah, this is because you have more than one ERC prompt in the buffer.
> 
> You are joining other groups by using "/JOIN #YADDA", correct?

Yes, I use /JOIN. 

> Use C-c C-j instead, and it won't write any extra ERC prompt into the
> current buffer.  
> 
> ERC prompts are read-only, and, as you've found out, won't be erased
> by the above macro.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

Re: [Erc-help] Re: Newbie questions

[Andreas S. <sc...@su...>]

da...@ad... (J. David Boyd) writes:

> Ah, this is because you have more than one ERC prompt in the buffer.
>
> You are joining other groups by using "/JOIN #YADDA", correct?
>
> Use C-c C-j instead, and it won't write any extra ERC prompt into the
> current buffer. =20

There are many ways to get multiple prompts in erc buffers.  Pretty much
any use of an erc command will do.

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."

Re: [Erc-help] Newbie questions

[Jorgen S. <fo...@fo...>]

Pascal J.Bourguignon <pj...@in...> writes:

> Hello, 
>
> I'm a new user of erc, and I have a couple of questions:
>
> - how to erase (/clean) a channel buffer?  erase-buffer complains for
>   read-only text. For now, the only solution I have is /leave and
>   /join #channel. (And I mean really removing all the buffer contents,
>   not jumping down!)

(defun erc-cmd-CLEAN ()
  "Clean the current erc server buffer."
  (save-excursion
    (let ((inhibit-read-only t))
      (delete-region (point-min)
                     (erc-bol)))))

> - the answers to /msg commands given in a #channel buffer go to the
>   server buffer.  How can one get them in the #channel buffer where
>   the /msg command was given?

You can customize erc-auto-query to make it open a new window when
someone sends you a message. ERC does not do the bookkeeping to
determine if and where a message was sent to someone so it can
find out where it should display a reply. But actually, the reply
should be displayed in the current window (or last active erc
window). Does it really show up only in the server buffer?

Greetings,
        -- Jorgen

-- 
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))

[Erc-help] Re: Newbie questions

[<da...@ad...>]

Pascal J.Bourguignon <pj...@in...> writes:

> J. David Boyd writes:
> > Pascal J.Bourguignon <pj...@in...> writes:
> > 
> > > Hello, 
> > > 
> > > I'm a new user of erc, and I have a couple of questions:
> > > 
> > > - how to erase (/clean) a channel buffer?  erase-buffer complains for
> > >   read-only text. For now, the only solution I have is /leave and
> > >   /join #channel. (And I mean really removing all the buffer contents,
> > >   not jumping down!)
> > > 
> > 
> > I just got this the other day from a user here, as I had the same
> > question.  Put this in your .emacs, and change the key definition to
> > something you like:
> > 
> > (fset 'ClearERC [?\C-p ?\C-e ?\C-  ?\M-< ?\C-w ?\M->])
> > (global-set-key (kbd "C-c C-x C-c") 'ClearERC)
> > 
> > I run this with point right after the ERC prompt.  It goes up a line,
> > moves to the end of the line, sets the point, moves to the beginning
> > of the buffer, kills the region, and moves to the end of the buffer
> 
> 
> Well, it works once, but thereafter, erc inserted some read-only text
> and it does not work anymore:
> 
> After 0 kbd macro iterations: byte-code: Text is read-only: #<buffer #lisp>
> 

Ah, this is because you have more than one ERC prompt in the buffer.

You are joining other groups by using "/JOIN #YADDA", correct?

Use C-c C-j instead, and it won't write any extra ERC prompt into the
current buffer.  

ERC prompts are read-only, and, as you've found out, won't be erased
by the above macro.

Dave

Re: [Erc-help] Newbie questions

[Pascal J.B. <pj...@in...>]

Damien Elmes writes:
> "Pascal J.Bourguignon" <pj...@in...> writes:
> 
> > Hello, 
> >
> > I'm a new user of erc, and I have a couple of questions:
> >
> > - how to erase (/clean) a channel buffer?  erase-buffer complains for
> >   read-only text. For now, the only solution I have is /leave and
> >   /join #channel. (And I mean really removing all the buffer contents,
> >   not jumping down!)
> 
> Try this:
> 
> (defun erc-cmd-CLEAR ()
>   (interactive)
>   (save-buffer)
>   (save-excursion
>     (let ((inhibit-read-only t))
>       (beginning-of-line)
>       (delete-region 1 (point)))))

Thank you. This works well.
 
> If you have logging enabled, it'll ensure it's saved in the log before
> deleting it from the screen. Remove the save-buffer line if you don't
> want that.
> 
> > - the answers to /msg commands given in a #channel buffer go to the
> >   server buffer.  How can one get them in the #channel buffer where
> >   the /msg command was given?
> 
> I don't think erc supports this by default. but you can make messages
> pop up in a separate buffer easily. c-h v erc-auto-query


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

[Erc-help] Re: Newbie questions

[<boj...@dd...>]

Pascal J.Bourguignon <pj...@in...> writes:

> - how to erase (/clean) a channel buffer?  erase-buffer complains for
>   read-only text. For now, the only solution I have is /leave and
>   /join #channel. (And I mean really removing all the buffer contents,
>   not jumping down!)


(let ((inhibit-read-only t)) (erase-buffer))


(also see `erc-truncate')

> - the answers to /msg commands given in a #channel buffer go to the
>   server buffer.  How can one get them in the #channel buffer where
>   the /msg command was given?

`erc-echo-notices-in-current-buffer' perhaps?

-- 
Johan Bockgård

[Erc-help] Re: Newbie questions

[Pascal J.B. <pj...@in...>]

J. David Boyd writes:
> Pascal J.Bourguignon <pj...@in...> writes:
> 
> > Hello, 
> > 
> > I'm a new user of erc, and I have a couple of questions:
> > 
> > - how to erase (/clean) a channel buffer?  erase-buffer complains for
> >   read-only text. For now, the only solution I have is /leave and
> >   /join #channel. (And I mean really removing all the buffer contents,
> >   not jumping down!)
> > 
> 
> I just got this the other day from a user here, as I had the same
> question.  Put this in your .emacs, and change the key definition to
> something you like:
> 
> (fset 'ClearERC [?\C-p ?\C-e ?\C-  ?\M-< ?\C-w ?\M->])
> (global-set-key (kbd "C-c C-x C-c") 'ClearERC)
> 
> I run this with point right after the ERC prompt.  It goes up a line,
> moves to the end of the line, sets the point, moves to the beginning
> of the buffer, kills the region, and moves to the end of the buffer


Well, it works once, but thereafter, erc inserted some read-only text
and it does not work anymore:

After 0 kbd macro iterations: byte-code: Text is read-only: #<buffer #lisp>

How can we remove all the read-only text attributes in a buffer?


> > - the answers to /msg commands given in a #channel buffer go to the
> >   server buffer.  How can one get them in the #channel buffer where
> >   the /msg command was given?
> > 
> 
> Can't help with this one...

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

[Erc-help] Re: Newbie questions

[<da...@ad...>]

Pascal J.Bourguignon <pj...@in...> writes:

> Hello, 
> 
> I'm a new user of erc, and I have a couple of questions:
> 
> - how to erase (/clean) a channel buffer?  erase-buffer complains for
>   read-only text. For now, the only solution I have is /leave and
>   /join #channel. (And I mean really removing all the buffer contents,
>   not jumping down!)
> 

I just got this the other day from a user here, as I had the same
question.  Put this in your .emacs, and change the key definition to
something you like:

(fset 'ClearERC [?\C-p ?\C-e ?\C-  ?\M-< ?\C-w ?\M->])
(global-set-key (kbd "C-c C-x C-c") 'ClearERC)

I run this with point right after the ERC prompt.  It goes up a line,
moves to the end of the line, sets the point, moves to the beginning
of the buffer, kills the region, and moves to the end of the buffer




> - the answers to /msg commands given in a #channel buffer go to the
>   server buffer.  How can one get them in the #channel buffer where
>   the /msg command was given?
> 

Can't help with this one...

Dave

[Erc-help] Re: Slow access to files using UNC path

[Stefan <mo...@ir...>]

>> How about choosing the file name based on the date the buffer is
>> created?
> Then restarting emacs 20 times in one day will result in an
> unnecessarily large amount of files.

Not if your "date" changes less than 20 times per day.
And in what way is that different from what happens if you choose the date
based on the time the buffer is saved?
I must still be missing something.

>> How about using "foo/bar-latest at first and switching to "foo/bar-<date>"
>> in before-save-hook?

> So theoretically bar-latest will never be written to? So basically
> you're suggesting that instead of a blank value in the
> buffer-file-name variable, we use something more misleading?

In what way is it more misleading?

> At the moment emacs does not easily facilitate the dynamic generation
> of a file name at save time.

Indeed, it doesn't.  The very idea of a buffer-file-name variable is based
on the premise that the buffer corresponds to one particular file.

> Your increasingly complicated suggestions would solve the problem, but
> this level of complexity in what is ultimately a hack in the first place
> seems unnecessary, IMHO.

I don't find "foo/bar-latest" more complex than "".  But maybe that's just me.

> If recent changes in emacs are going to prevent "" as a
> buffer-file-name from working,

It already isn't working if you turn on uniquify.  Nothing to do with
recent changes.  Your choice of "" has fundamentally two problems:
1 - it's not a valid file name (and it's not an absolute file name).
2 - it's not unique.  Emacs likes to have at most one buffer with a given
    file name.
None of those two necessarily cause Emacs to break, but they both induce
various more or less minor problems.

> then perhaps it would be better to have a save hook which is called prior
> to the buffer-file-name being checked, so these elaborate hacks are not
> necessary in the first place.

Now that's probably true.


        Stefan

Re: [Erc-help] Newbie questions

[Damien E. <er...@re...>]

"Pascal J.Bourguignon" <pj...@in...> writes:

> Hello, 
>
> I'm a new user of erc, and I have a couple of questions:
>
> - how to erase (/clean) a channel buffer?  erase-buffer complains for
>   read-only text. For now, the only solution I have is /leave and
>   /join #channel. (And I mean really removing all the buffer contents,
>   not jumping down!)

Try this:

(defun erc-cmd-CLEAR ()
  (interactive)
  (save-buffer)
  (save-excursion
    (let ((inhibit-read-only t))
      (beginning-of-line)
      (delete-region 1 (point)))))

If you have logging enabled, it'll ensure it's saved in the log before
deleting it from the screen. Remove the save-buffer line if you don't
want that.

> - the answers to /msg commands given in a #channel buffer go to the
>   server buffer.  How can one get them in the #channel buffer where
>   the /msg command was given?

I don't think erc supports this by default. but you can make messages
pop up in a separate buffer easily. c-h v erc-auto-query

Cheers,

Damien

[Erc-help] Re: Slow access to files using UNC path

[Damien E. <da...@re...>]

Stefan Monnier <mo...@ir...> writes:

> than what?  What alternatives have you considered?  How is the buffer-save
> triggered (is it triggered by a timer, by the user selecting the buffer and
> hitting C-x C-s, by some other command in the main ERC buffer, indirectly by
> save-some-buffers, ...)?

Depending on the user's preferences, all of the above. Also possibly
by certain network activity.

> How about choosing the file name based on the date the buffer is
> created?

Then restarting emacs 20 times in one day will result in an
unnecessarily large amount of files.

> How about using "foo/bar-latest at first and switching to "foo/bar-<date>"
> in before-save-hook?

So theoretically bar-latest will never be written to? So basically
you're suggesting that instead of a blank value in the
buffer-file-name variable, we use something more misleading?

> How about always using "foo/bar-latest" as buffer-file-name and
> link/copy/move the file to "foo/bar-<date>" in after-save-hook?
>
> How about using "foo/bar-<date>" at buffer creation and in before-save-hook
> update the "<date>" part if necessary (if the date only includes the month,
> it's unlikely to change, and if the user restarts Emacs every day, the same
> will hold even if the date includes the day)?

At the moment emacs does not easily facilitate the dynamic generation
of a file name at save time. Your increasingly complicated suggestions
would solve the problem, but this level of complexity in what is
ultimately a hack in the first place seems unnecessary, IMHO.

If recent changes in emacs are going to prevent "" as a
buffer-file-name from working, then perhaps it would be better to have
a save hook which is called prior to the buffer-file-name being
checked, so these elaborate hacks are not necessary in the first place.

>> as it allows us to compute the file name on demand rather than attempt to
>> keep it updated by something like a timer.
>
> Hmmm.... doing it in a timer?  That sounds like trouble,

Exactly.

Cheers,

Damien

[Erc-help] Newbie questions

[Pascal J.B. <pj...@in...>]

Hello, 

I'm a new user of erc, and I have a couple of questions:

- how to erase (/clean) a channel buffer?  erase-buffer complains for
  read-only text. For now, the only solution I have is /leave and
  /join #channel. (And I mean really removing all the buffer contents,
  not jumping down!)

- the answers to /msg commands given in a #channel buffer go to the
  server buffer.  How can one get them in the #channel buffer where
  the /msg command was given?



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.

[Erc-help] Re: Slow access to files using UNC path

[Stefan M. <mo...@ir...>]

>>> The rationale behind "" was that a non-zero string may be
>>> misinterpreted by a user/programmer as a real path, when its value
>>> would just be ignored.
>> 
>> Without explaining to use the reason why the file-name has to change, it's
>> difficult to know what's the best solution.

> Doing it this way allows people to store log files based on the date a
> buffer is saved, such as using a new log file each month, or day.
> Hooking into the save mechanism is a lot more straightforward

than what?  What alternatives have you considered?  How is the buffer-save
triggered (is it triggered by a timer, by the user selecting the buffer and
hitting C-x C-s, by some other command in the main ERC buffer, indirectly by
save-some-buffers, ...)?

How about choosing the file name based on the date the buffer is created?

How about using "foo/bar-latest at first and switching to "foo/bar-<date>"
in before-save-hook?

How about always using "foo/bar-latest" as buffer-file-name and
link/copy/move the file to "foo/bar-<date>" in after-save-hook?

How about using "foo/bar-<date>" at buffer creation and in before-save-hook
update the "<date>" part if necessary (if the date only includes the month,
it's unlikely to change, and if the user restarts Emacs every day, the same
will hold even if the date includes the day)?

> as it allows us to compute the file name on demand rather than attempt to
> keep it updated by something like a timer.

Hmmm.... doing it in a timer?  That sounds like trouble,


        Stefan

[Erc-help] Re: Slow access to files using UNC path

[Damien E. <da...@re...>]

Stefan <mo...@ir...> writes:

>> The rationale behind "" was that a non-zero string may be
>> misinterpreted by a user/programmer as a real path, when its value
>> would just be ignored.
>
> Without explaining to use the reason why the file-name has to change, it's
> difficult to know what's the best solution.

Doing it this way allows people to store log files based on the date a
buffer is saved, such as using a new log file each month, or day.
Hooking into the save mechanism is a lot more straightforward as it
allows us to compute the file name on demand rather than attempt to
keep it updated by something like a timer.

Cheers,

Damien

[Erc-help] Re: Slow access to files using UNC path

[Stefan <mo...@ir...>]

> The rationale behind "" was that a non-zero string may be
> misinterpreted by a user/programmer as a real path, when its value
> would just be ignored.

Without explaining to use the reason why the file-name has to change, it's
difficult to know what's the best solution.


        Stefan

[Erc-help] Re: Slow access to files using UNC path

[Richard S. <rm...@gn...>]

    The rationale behind "" was that a non-zero string may be
    misinterpreted by a user/programmer as a real path,

(Side issue reminder: please call it a "file name".  In GNU we use the
term "path" only for lists of directories to search, like $PATH.)

[Erc-help] Re: Slow access to files using UNC path

[Damien E. <da...@re...>]

Stefan <mo...@ir...> writes:

> Why use "" rather than something else (since you say it's ignored anyway)?
> I suspect "" will create other problems than just with this new VC code.
> E.g. I wouldn't be surprised to see it bump into uniquify for
> example.

The rationale behind "" was that a non-zero string may be
misinterpreted by a user/programmer as a real path, when its value
would just be ignored. We could probably change ERC to name buffers
with a fake path like "/foo/bar/baz", but that seems like even more of
a hack. The alternative would be a more elegant way for
basic-save-buffer to decide if it should prompt for a file name or
continue on.

Cheers,

Damien