headers
Richard Stallman | 1 Mar 2003 03:25
Picon
Picon

Re: file-relative-name and remote files

    One more problem: The syntax to invoke the Tramp file handler
    is "\`/[^/:]+:". So the handler is not invoked in the call
    (expand-file-name "/emacs/../larsh <at> galois.math.ku.dk:."). The
    call returns "/larsh <at> galois.math.ku.dk:." but it should return
    "/larsh <at> galois.math.ku.dk:/home/l/larsh".

I am not sure whether "/larsh <at> galois.math.ku.dk:." is correct, but it
might be.  I don't think it should return
"/larsh <at> galois.math.ku.dk:/home/l/larsh" because that requires
contacting the remote host, and it is better if expand-file-name does
its work locally.

    Btw, if the part after the colon is not an absolute filename, that is
    interpreted as being relative to the remote home dir.  What happens
    if I open a file "/foo:../bar"?  Is that the same as "/foo:/../bar"
    and therefore the same as "/bar"?

It isn't the same as "/foo:/../bar", just as
"/foo:bar" is not equivalent to "/foo:/bar".

Hmm, this raises the issue of what expand-file-name should do with
"/foo:../..".  I guess it must leave that unchanged, which means that
the expand-file-name handler for these file names should be rather
careful in what it does to simplify whatever part of the name comes
after.  It is not correct to simplify /X/../Y into /Y when /X
is a remote prefix.

This seems to have implications about file-relative-name.  Suppose we
ask for
(Continue reading)

Permalink | Reply | 5 comments |
headers
Richard Stallman | 1 Mar 2003 03:26
Picon
Picon

Re: proposed new variable `emacs-lisp-docstring-fill-column'

	(defcustom emacs-lisp-docstring-fill-column 65
	  "Value of `fill-column' to use when filling a docstring.
	Any non-integer value means do not use a different value of
	`fill-column' when filling docstrings."
	  :type '(choice (integer)
			 (const :tag "Use the current `fill-column'" t))
	  :group 'lisp)

It sounds like a good idea; would you like to implement the code
to actually use it, and show us that?
Permalink | Reply | 7 comments |
headers
Richard Stallman | 1 Mar 2003 03:26
Picon
Picon

Re: Close .emacs file after customization?

    > We could make Custom kill the buffer if it didn't exist before
    > Custom created it.

    That's probably preferable to prevent confusion.

Would someone like to implement this?
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Mar 2003 03:25
Picon
Picon

Re: Rmail and headers in other than US-ASCII (RFC2047 encoded words)

    > I would like to have just one, and I would like it to be Mail mode.

    Should it also work for news postings?

That would be a good feature for the merged mode to have.  If done in
a simple clean way, that would be a small aspect of the mode--just
changes in the code for sending the message.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Mar 2003 03:26
Picon
Picon

Re: Request for enhancement: Scrolling (etc.) in incremental search.

    The entire new feature is enabled by a customization switch
    (isearch-allow-scroll).  I set it enabled in my patch, but it could
    (should?) be disabled by default.

I have no objections to it if it is disabled by default.

    Were you thinking of something like
    (define-key isearch-mode-map "\M-s" 'isearch-toggle-scrolling), analogous
    to isearch-toggle-case-fold?

I don't like the idea of stealing yet another command.
I would just make a user option to turn this on and off.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Mar 2003 03:25
Picon
Picon

Re: file-relative-name and remote files

    I suggest the following implementation of file-relative-name.
    It does not require a new file handler operation, it detects
    remote files in the same way as file-remote-p do. Please see
    the doc string for further explanation.

This seems like the right general approach for making that change.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Mar 2003 03:26
Picon
Picon

Re: BUG REPORT: `kill-buffer-query-functions'

    When making this hook buffer local, the 't add at the end is called as a 
    function, and of course it's not a function.

Would you please send a precise test case?
Permalink | Reply | 4 comments |
headers
Le Wang | 1 Mar 2003 04:08
Picon
Favicon

Re: BUG REPORT: `kill-buffer-query-functions'

Richard Stallman wrote:

>     When making this hook buffer local, the 't add at the end is called as a
>     function, and of course it's not a function.
> 
> Would you please send a precise test case?

Sure thing.

1. emacs -q

2. paste this code in scratch

(defun test-query ()
  (if (and (buffer-modified-p)
           (not (y-or-n-p (format "Abandon changes to %s? (y/n) "
                                  (buffer-name)))))
      nil
    t))

(add-hook 'kill-buffer-query-functions 'test-query nil t)

3. eval it.

4. <M-x> kill-this-buffer

5. answer `y' when prompted.

6. Error: Symbol's function definition is void: t
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luc Teirlinck | 1 Mar 2003 04:41
Picon

some dired hints should be background jobs

Dan Jacobson wrote:

    idea, in dired with the cursor on a .pdf file, when we hit ! we get
    ! on man.pdf: [xpdf]
    [by the way, I just copy-and-pasted that line from the minibuffer
    prompt into this message and can't edit it one bit!]
    OK, but better a better default would be running xpdf in the
    background, for which the user has to type "xpdf * &" which BTW
    creates an distracting Async window. Yes, all that can be customized
    on one's own.

The `v' command (in dired) currently will run xpdf and friends in the
foreground, making it impossible to continue using emacs without
killing the xpdf job.  I agree that background would be better.
Changing the default of ! to run background jobs seems trivial, but
one would be stuck with the Async window popping up, which I agree is
distracting.  I also believe it is usually useless.  If one
inadvertently kills the useless buffer, the background job is gone
too.  I myself have M-RETURN bound (in dired) to a command that will
run xpdf and friends in the background, without any Async window
appearing.  A separate window (or frame) is created if necessary to
display output generated by the process, such as error messages and
the like, but only if necessary.  (Usually it is not.)  If people
would agree that this would be a good idea, I could send code for a
command that would either replace the `v' binding or would have a new
binding, say M-RETURN or whatever.  I could not just use my own
current code literally, since it would have to be stripped of personal
idiosyncrasies, but I do not believe that would be difficult to do.

Sincerely,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Swift | 1 Mar 2003 05:05
Picon
Favicon

Re: proposed new variable `emacs-lisp-docstring-fill-column'


    rms> It sounds like a good idea; would you like to implement the code
    rms> to actually use it, and show us that?

Here's the whole change.  I've been using it happily for a dozen or
two hours of working in Emacs Lisp mode.  I'm noticing other bugs in
filling ELisp, but they're not due to this change.

Using the new variable is as simple as adding a single `let' binding,
marked with ;;; HERE.

You may notice the function has other changes, so I should list them
all now:

  (1) use the new variable `emacs-lisp-docstring-fill-column'
  (2) add "`(" to `paragraph-start' so that `defmacro's whose bodies
      begin with backquote (i.e. most of them) will fill properly.
      This requires ?( to be escaped when "`(" begins a line in a
      docstring.   I think good style would escape all ?( chars in
      a docstring. 
  (3) recognize (and thus do not fill) a docstring's first line when
      it ends with ?, as well as ?.  Checkdoc-mode optionally permits
      a comma, so let's have filling recognize that situation.
  (4) revise the comments

(defcustom emacs-lisp-docstring-fill-column 65
  "Value of `fill-column' to use when filling a docstring.
Any non-integer value means do not use a different value of
`fill-column' when filling docstrings."
  :type '(choice (integer)
(Continue reading)

Permalink | Reply | 6 comments |

Gmane