Re: Slow access to files using UNC path

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

Hello,
 This is a modified patch (original patch from Mr.KOBAYASHI Yasuhiro)
including Stefan Monnier's suggested regexp. I do not know where to
add the defvar "vc-hostname-fs-path-re" (currently, I have added in
vc-arch.el as autoloads of vc-arch.el appears before vc-mcvs.el in
loaddefs.el. I know this is error prone assumption, this is the best I
could do due to technical limitations) and this should be fixed. This
could also be a defcustom (I am no expert, just a suggestion).
I have tested this patch and it works fine and does what it is
intended to do. I request the patch to be reviewed and someone with
write access to CVS to kindly apply the patch after suitable
modifications to place the definition & default
"vc-hostname-fs-path-re" correctly.

with best regards,
dhruva

-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[-- Attachment #2: unc.patch --]
[-- Type: application/octet-stream, Size: 1729 bytes --]

*** d:/tmp/cvs/emacs/lisp/vc-arch.el	2004-07-04 14:55:35.031250000 +0530
--- vc-arch.el	2004-09-01 10:45:49.573425500 +0530
***************
*** 71,81 ****
--- 71,84 ----
  ;; new functions when we reload this file.
  (put 'Arch 'vc-functions nil)
  
+ ;;;###autoload (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)" "Regular expression to identify remote folders")
  ;;;###autoload (defun vc-arch-registered (file)
  ;;;###autoload   (let ((dir file))
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; Avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "{arch}" dir))
*** d:/tmp/cvs/emacs/lisp/vc-mcvs.el	2004-05-31 14:05:26.938250000 +0530
--- vc-mcvs.el	2004-09-01 10:42:08.593468500 +0530
*************** This is only meaningful if you don't use
*** 118,123 ****
--- 118,125 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Slow access to files using UNC path

[KOBAYASHI Yasuhiro]

In message Re: Slow access to files using UNC path
 Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> wrote:

> I request the patch to be reviewed and someone with
> write access to CVS to kindly apply the patch after suitable
> modifications to place the definition & default
> "vc-hostname-fs-path-re" correctly.

What about the following patch:

*** c:/home/kobayays/src/emacs/lisp/vc-mcvs.el~	Wed Sep  1 15:17:12 2004
--- c:/home/kobayays/src/emacs/lisp/vc-mcvs.el	Wed Sep  1 15:04:40 2004
***************
*** 118,123 ****
--- 118,124 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))
*** c:/home/kobayays/src/emacs/lisp/vc-arch.el~	Wed Sep  1 15:16:10 2004
--- c:/home/kobayays/src/emacs/lisp/vc-arch.el	Wed Sep  1 15:04:06 2004
***************
*** 76,81 ****
--- 76,82 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "{arch}" dir))
*** c:/home/kobayays/src/emacs/lisp/vc.el~	Wed Sep  1 15:16:40 2004
--- c:/home/kobayays/src/emacs/lisp/vc.el	Wed Sep  1 15:05:08 2004
***************
*** 644,649 ****
--- 644,652 ----
    :type '(repeat number)
    :group 'vc)
  
+ ;;;###autoload
+ (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)\\'")
+ 
  ;; vc-annotate functionality (CVS only).
  (defvar vc-annotate-mode nil
    "Variable indicating if VC-Annotate mode is active.")

-- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>

Re: Slow access to files using UNC path

[Andre Spiegel]

On Wed, 2004-09-01 at 08:31, KOBAYASHI Yasuhiro wrote:

> What about the following patch:

> *** c:/home/kobayays/src/emacs/lisp/vc.el~	Wed Sep  1 15:16:40 2004
> --- c:/home/kobayays/src/emacs/lisp/vc.el	Wed Sep  1 15:05:08 2004
> ***************
> *** 644,649 ****
> --- 644,652 ----
>     :type '(repeat number)
>     :group 'vc)
>   
> + ;;;###autoload
> + (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)\\'")
> + 
>   ;; vc-annotate functionality (CVS only).
>   (defvar vc-annotate-mode nil
>     "Variable indicating if VC-Annotate mode is active.")

That doesn't look right.  If you want to ensure every backend sees the
variable when needed, place it into vc-hooks.el (this is the
always-loaded portion of VC).  It needs to have a good doc string
though.  Not having followed the discussion until now, I have hardly any
idea what the variable is supposed to do.  The doc string suggested in
an earlier patch:

  "Regular expression to identify remote folders"

isn't much help either.  ("Folder" is not an Emacs term, to begin
with.)  Please clarify.  Also, if this is a general mechanism to
identify directories on remote hosts, I wonder if only VC is concerned
with it.  Perhaps the regexp needs to go to a different place
altogether?

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

hello,

On Wed, 01 Sep 2004 08:42:47 +0200, Andre Spiegel <spiegel@gnu.org> wrote:
> > + ;;;###autoload
> > + (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)\\'")
> > +
> >   ;; vc-annotate functionality (CVS only).
> >   (defvar vc-annotate-mode nil
> >     "Variable indicating if VC-Annotate mode is active.")
> 
> That doesn't look right.  If you want to ensure every backend sees the
> variable when needed, place it into vc-hooks.el (this is the
> always-loaded portion of VC).  It needs to have a good doc string
> though.  Not having followed the discussion until now, I have hardly any
> idea what the variable is supposed to do.  The doc string suggested in
> an earlier patch:
> 
>   "Regular expression to identify remote folders"
> 
> isn't much help either.  ("Folder" is not an Emacs term, to begin
> with.)  Please clarify.  Also, if this is a general mechanism to

Agreed. The whole chain started with my observation of very slow
access to files under UNC when compared to XEmacs. In an earlier
posting, I was told it was due to XEmacs using something like
find-file-literally and Emacs using find-file (which has lot of
hooks). It was debuged and found by Mr.KOBAYASHI Yasuhiro and the
original patch. I found the regex was not working for me from the
original patch and Stefan came up with the current regexp which
_tremendously_ speeds up accessing files over UNC. They have now
generalized for UNC,net and afs (not sure of this ,though)

> identify directories on remote hosts, I wonder if only VC is concerned
> with it.  Perhaps the regexp needs to go to a different place
> altogether?

I agree with you here. This variable could be in a more generic
location with a different name too. Ex: remote-folder-regex or
something like that and this should be defcustom. The default can be
the one in the patch.

with best regards,
dhruva

-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Wed, 1 Sep 2004 15:20:03 +0530, Dhruva Krishnamurthy > 
> > identify directories on remote hosts, I wonder if only VC is concerned
> > with it.  Perhaps the regexp needs to go to a different place
> > altogether?
> 
> I agree with you here. This variable could be in a more generic
> location with a different name too. Ex: remote-folder-regex or
> something like that and this should be defcustom. The default can be
> the one in the patch.
> 
> 

I did some lookup into files.el, there is a function file-remote-p, I
guess we should have a function dir-remote-p. This function can do a
string-match with the regular expression (defcustom) if present or use
the same logic used in file-remote-p (modify to check directory
instead of file). IMHO, this is a clean solution along the lines of
existing code.

with best regards,
dhruva
-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:

> I did some lookup into files.el, there is a function file-remote-p, I
> guess we should have a function dir-remote-p.

A directory is also a file, so file-remote-p should work also on
directories.  But file-remote-p does actually test something different,
namely if you need a special method to access a file.  IIUC an UNC path
can be accessed by the normal file operations, so it is not a remote
location according to file-remote-p.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Wed, 01 Sep 2004 14:13:46 +0200, Andreas Schwab <schwab@suse.de> wrote:
> can be accessed by the normal file operations, so it is not a remote
> location according to file-remote-p.

I meant the function name is somewhat similar to what we want but not
the behavior. IMO, ideally in Emacs, something-p (like symbolp or
functionp..) is used to test the argument, along the same line, I
thought file-remote-p or dir-remote-p would be intuitive to test
whether file/dir is a remote or not.
 A suggestion, to avoid confusion by modifying file-remote-p would be
to use file-local-p

(defvar remote-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)") 
(defun file-local-p (file)
 "Returns t if local file or nil for remote file"
 (not (string-match remote-fs-path-re file)))

and use (not (file-local-p dir)) in the earlier patch...

with best regards,
dhruva
-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:

>  A suggestion, to avoid confusion by modifying file-remote-p would be
> to use file-local-p
>
> (defvar remote-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)") 
> (defun file-local-p (file)
>  "Returns t if local file or nil for remote file"

I don't think you should use the term "remote" here, it already has a
specific meaning in Emacs not matching the intended meaning here.  It
should be made clear that this predicate is not just the opposite of
file-remote-p.  Something like "network filesystem" might be better.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[Stefan Monnier]

> file-remote-p.  Something like "network filesystem" might be better.

The problem is that network filesystems are not the real problem:
If your home dir is accessed via NFS, you don't have to put it in
that regexp.  What needs to be in that regexp are the paths for which the
filename is interpreted as a hostname (typicaly to then mount a network
filesystem).


        Stefan

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Wed, 01 Sep 2004 08:42:47 +0200, Andre Spiegel <spiegel@gnu.org> wrote:
> On Wed, 2004-09-01 at 08:31, KOBAYASHI Yasuhiro wrote:
> 
> That doesn't look right.  If you want to ensure every backend sees the
> variable when needed, place it into vc-hooks.el (this is the
> always-loaded portion of VC).  It needs to have a good doc string
> though.  Not having followed the discussion until now, I have hardly any
> idea what the variable is supposed to do.  The doc string suggested in
> an earlier patch:
> 
>   "Regular expression to identify remote folders"
> 
> isn't much help either.  ("Folder" is not an Emacs term, to begin
> with.)  Please clarify.  Also, if this is a general mechanism to
> identify directories on remote hosts, I wonder if only VC is concerned
> with it.  Perhaps the regexp needs to go to a different place
> altogether?

Done the changes by putting the variable in vc-hooks.el with better
documentation. I have used this patch and has worked with no issues so
far. I request the patch to be reviewed and put into CVS head (so that
it gets tested well by the Emacs developer community).
 The attached patch is as on 8th Sept 2004. I have taken the latest
changes to vc-arch.el by Stefan.

with best regards,
dhruva

-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[-- Attachment #2: unc.patch --]
[-- Type: application/octet-stream, Size: 2367 bytes --]

*** D:/tmp/cvs/emacs/lisp/vc-hooks.el	2004-04-24 02:31:07.000000000 +0530
--- vc-hooks.el	2004-09-08 12:07:35.518161100 +0530
*************** BACKEND, use `vc-handled-backends'.")
*** 52,57 ****
--- 52,64 ----
  (defvar vc-header-alist ())
  (make-obsolete-variable 'vc-header-alist 'vc-BACKEND-header)
  
+ (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)"
+   "Regex variable used to avoid determining whether file is under vc-arch
+ or vc-mcvs. The default regexp prevents the determination of type of vc for
+ folders in UNC, net and afs. This speeds up opening of files by not trying to
+ determine whether file is under vc. This can be modified by user to match a 
+ different path or paths")
+ 
  (defcustom vc-handled-backends '(RCS CVS SVN SCCS Arch MCVS)
    ;; Arch and MCVS come last because they are per-tree rather than per-dir.
    "*List of version control backends for which VC will be used.
*** D:/tmp/cvs/emacs/lisp/vc-mcvs.el	2004-05-31 14:05:26.938250000 +0530
--- vc-mcvs.el	2004-09-08 12:07:35.548205800 +0530
*************** This is only meaningful if you don't use
*** 118,123 ****
--- 118,125 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))
*** D:/tmp/cvs/emacs/lisp/vc-arch.el	2004-09-08 09:35:36.187974400 +0530
--- vc-arch.el	2004-09-08 12:07:35.608295200 +0530
***************
*** 77,82 ****
--- 77,84 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; Avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "{arch}" dir))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Slow access to files using UNC path

[Kim F. Storm]

Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:

> + (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)"
> +   "Regex variable used to avoid determining whether file is under vc-arch
> + or vc-mcvs. The default regexp prevents the determination of type of vc for
> + folders in UNC, net and afs. This speeds up opening of files by not trying to
> + determine whether file is under vc. This can be modified by user to match a 
> + different path or paths")

In Emacs, a 'path' is something like load-path, and we never use the
term 'path' for a directory name or file name.

IMO, a better name would be something like `vc-ignore-file-re'.

(defvar vc-ignore-file-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)"
  "Regular expression matching file names that are not under vc control.
Specifically, it is used to avoid determining whether file is under vc-arch
or vc-mcvs. The default regexp prevents the determination of type of vc for
folders in UNC, net and afs. This speeds up opening of files by not trying to
determine whether file is under vc. This can be modified by user to match a 
different directory or file names.")


BTW, I don't understand why this is specific for vc-arch and vc-mcvs ?






> + 
>   (defcustom vc-handled-backends '(RCS CVS SVN SCCS Arch MCVS)
>     ;; Arch and MCVS come last because they are per-tree rather than per-dir.
>     "*List of version control backends for which VC will be used.
> *** D:/tmp/cvs/emacs/lisp/vc-mcvs.el	2004-05-31 14:05:26.938250000 +0530
> --- vc-mcvs.el	2004-09-08 12:07:35.548205800 +0530
> *************** This is only meaningful if you don't use
> *** 118,123 ****
> --- 118,125 ----
>   ;;;###autoload     (while (and (stringp dir)
>   ;;;###autoload                 (not (equal
>   ;;;###autoload                       dir (setq dir (file-name-directory dir))))
> + ;;;###autoload                 ;; avoid searching no existing computer on Windowz.
> + ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
>   ;;;###autoload                 dir)
>   ;;;###autoload       (setq dir (if (file-directory-p
>   ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))
> *** D:/tmp/cvs/emacs/lisp/vc-arch.el	2004-09-08 09:35:36.187974400 +0530
> --- vc-arch.el	2004-09-08 12:07:35.608295200 +0530
> ***************
> *** 77,82 ****
> --- 77,84 ----
>   ;;;###autoload     (while (and (stringp dir)
>   ;;;###autoload                 (not (equal
>   ;;;###autoload                       dir (setq dir (file-name-directory dir))))
> + ;;;###autoload                 ;; Avoid searching no existing computer on Windowz.
> + ;;;###autoload                 (not (string-match vc-hostname-fs-path-re dir))
>   ;;;###autoload                 dir)
>   ;;;###autoload       (setq dir (if (file-directory-p
>   ;;;###autoload                      (expand-file-name "{arch}" dir))
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Slow access to files using UNC path

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> In Emacs, a 'path' is something like load-path, and we never use the
> term 'path' for a directory name or file name.
>
> IMO, a better name would be something like `vc-ignore-file-re'.

Also note that the suffix `-regexp' is both clearer and much more common
(in emacs at least). :-)

[and it looks those variables which _do_ use `-re' are almost all in
code written by the same person.... :]

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy it into your sig so it can spread.

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Wed, 08 Sep 2004 10:18:14 +0200, Kim F. Storm <storm@cua.dk> wrote:
> Dhruva Krishnamurthy <dhruva.krishnamurthy@gmail.com> writes:
> 
> IMO, a better name would be something like `vc-ignore-file-re'.
> 
> (defvar vc-ignore-file-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)"
>   "Regular expression matching file names that are not under vc control.
> Specifically, it is used to avoid determining whether file is under vc-arch
> or vc-mcvs. The default regexp prevents the determination of type of vc for
> folders in UNC, net and afs. This speeds up opening of files by not trying to
> determine whether file is under vc. This can be modified by user to match a
> different directory or file names.")

Accept, the above looks much better. if I make a new patch and submit,
will someone check it in? I have no write access.

> BTW, I don't understand why this is specific for vc-arch and vc-mcvs ?
> 

>From my understanding after reading comments in vc.el (Adding support
for other backends), vc-backend-registered is implemented for the new
"backend". I did a grep and found only "arch" and "mcvs" implements
this. So, the fix is isolated to these two files.

with best regards,
dhruva
-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Stefan]

>> + (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)"
>> +   "Regex variable used to avoid determining whether file is under vc-arch
>> + or vc-mcvs. The default regexp prevents the determination of type of vc for
>> + folders in UNC, net and afs. This speeds up opening of files by not trying to
>> + determine whether file is under vc. This can be modified by user to match a 
>> + different path or paths")

> In Emacs, a 'path' is something like load-path, and we never use the
> term 'path' for a directory name or file name.

Sorry 'bout that.

> IMO, a better name would be something like `vc-ignore-file-re'.

I disagree and I also disagree with the proposed docstring.
We should document what the variable is meant for, not how it's used.
It's meant for filenames which are interpreted by the system as hostnames.

VC uses this variable to avoid looking up non-exitent host names.

> folders in UNC, net and afs. This speeds up opening of files by not trying to
> determine whether file is under vc.

This makes it sound like it's always slow to determine whether a file is
under VC or not, whereas it's normally not the case.  It's only the case for
those special cases which we try to eliminate with this variable: the case
where the filename is used as a hostname and can thus lead to inordinate
waits (timeouts and stuff like that).

> BTW, I don't understand why this is specific for vc-arch and vc-mcvs ?

It's not, but since only VC uses it as of now, it seems to make sense to
only add it in vc-hooks.el.  When some other package finds a use for such
a thing, we can move it (and maybe change it along the way: it may turn out
that something slightly different will be needed at that point).


        Stefan


PS: As for the patch, it still misses the two other places (in the same
file) where we do the same thing again.

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Wed, 08 Sep 2004 07:55:51 -0400, Stefan <monnier@iro.umontreal.ca> wrote:
> PS: As for the patch, it still misses the two other places (in the same
> file) where we do the same thing again.
> 

I have reached the end (with my limited knowledge of elisp and vc). I
will not be technically capable to do this, I request the elisp gurus
to handle this and make this file opening speedup available to all
those affected.

with best regards,
dhruva
-- 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Stefan Monnier]

> On Wed, 08 Sep 2004 07:55:51 -0400, Stefan <monnier@iro.umontreal.ca> wrote:
>> PS: As for the patch, it still misses the two other places (in the same
>> file) where we do the same thing again.
>> 

> I have reached the end (with my limited knowledge of elisp and vc). I
> will not be technically capable to do this, I request the elisp gurus
> to handle this and make this file opening speedup available to all
> those affected.

You can do it, Dhruva!
If you look at the functions you changed (which are all prefixed
with ;;;###autoload), you'll see that they are defined a second time (but
this time not prefixed with ;;;###autoload) in each file.


        Stefan

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Thu, 09 Sep 2004 16:54:22 -0400, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> --- orig/lisp/vc-hooks.el
> +++ mod/lisp/vc-hooks.el
> @@ -52,6 +52,12 @@
>  (defvar vc-header-alist ())
>  (make-obsolete-variable 'vc-header-alist 'vc-BACKEND-header)
> 
> +(defvar vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)\\'"
> + "Regexp matching directory names that are not under VC's control.
> +The default regexp prevents fruitless and time-consuming attempts

The above regexp does not work. The working regexp (when I try to open
a file at '//wolfdei/d/users/dhruva/_emacs') is as follows:
(defvar vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")

Hence, if I put the following line in my _emacs (dot emacs), it works fine:
(setq vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")

with best regards,
dhruva

-- 
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Stefan Monnier]

>> +(defvar vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)\\'"
>> + "Regexp matching directory names that are not under VC's control.
>> +The default regexp prevents fruitless and time-consuming attempts

> The above regexp does not work. The working regexp (when I try to open
> a file at '//wolfdei/d/users/dhruva/_emacs') is as follows:
> (defvar vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")

As explained, such a regexp will indeed stop VC from mucking around in //
but it will do that *everywhere*, which is not what you want if your home
directory is on //myserver/myhome since it means that VC just won't work at
all for you.


        Stefan

Re: Slow access to files using UNC path

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 2004-09-12  Stefan Monnier  <monnier@iro.umontreal.ca>

> 	* vc-hooks.el (vc-ignore-dir-regexp): New var.
> 	(vc-registered): Use it.
> 	(vc-find-root): New fun.

> ***************
> *** 315,325 ****
>   file was previously registered under a certain backend, then that
>   backend is tried first."
>     (let (handler)
> !     (if (boundp 'file-name-handler-alist)
> !   	(setq handler (find-file-name-handler file 'vc-registered)))
> !     (if handler
> !         ;; handler should set vc-backend and return t if registered
> !   	(funcall handler 'vc-registered file)
>         ;; There is no file name handler.
>         ;; Try vc-BACKEND-registered for each handled BACKEND.
>         (catch 'found
> --- 335,347 ----
>   file was previously registered under a certain backend, then that
>   backend is tried first."
>     (let (handler)
> !     (cond
> !      ((string-match vc-ignore-dir-regexp (file-name-directory file)) nil)
> !      ((and (boundp 'file-name-handler-alist)
> !           (setq handler (find-file-name-handler file 'vc-registered)))
> !       ;; handler should set vc-backend and return t if registered
> !       (funcall handler 'vc-registered file))
> !      (t
>         ;; There is no file name handler.
>         ;; Try vc-BACKEND-registered for each handled BACKEND.
>         (catch 'found

This change is problematic for buffers where buffer-file-name is ""
(like ERC server buffers in my case), file-name-directory returns nil so
string-match signals an error.  It makes it impossible to quit Emacs
(you need to kill all such buffers manually).

How about the following fix?

--- orig/lisp/vc-hooks.el
+++ mod/lisp/vc-hooks.el
@@ -336,7 +336,10 @@
 backend is tried first."
   (let (handler)
     (cond
-     ((string-match vc-ignore-dir-regexp (file-name-directory file)) nil)
+     ((and
+       (file-name-directory file)
+       (string-match vc-ignore-dir-regexp (file-name-directory file)))
+      nil)
      ((and (boundp 'file-name-handler-alist)
           (setq handler (find-file-name-handler file 'vc-registered)))
       ;; handler should set vc-backend and return t if registered

-- 
Romain Francoise <romain@orebokech.com> | I've become someone else's
it's a miracle -- http://orebokech.com/ | nightmare...

Re: Slow access to files using UNC path

[Stefan]

> This change is problematic for buffers where buffer-file-name is ""
> (like ERC server buffers in my case), file-name-directory returns nil so
> string-match signals an error.  It makes it impossible to quit Emacs
> (you need to kill all such buffers manually).

> How about the following fix?

Hmm... I personally expect buffer-file-name to be an absolute file name (or
nil).  Admittedly, the docstring doesn't say that, so maybe your fix is
indeed in order (or else the docstring of buffer-file-name should be fixed).

But in any case buffer-file-name should never be "" IMHO, and I consider
this to be a bug in ERC.


        Stefan

Re: Slow access to files using UNC path

[Romain Francoise]

Stefan <monnier@iro.umontreal.ca> writes:

> I personally expect buffer-file-name to be an absolute file name (or
> nil).

Right.  Other places in Emacs seem to expect that too (see
get-file-buffer).

> But in any case buffer-file-name should never be "" IMHO, and I consider
> this to be a bug in ERC.

Even so, it doesn't sound unreasonable to check that we're not calling
string-match on nil, in any case...

-- 
Romain Francoise <romain@orebokech.com> | And you never lay down and
it's a miracle -- http://orebokech.com/ | you never stay home...

Re: Slow access to files using UNC path

[Adrian Aichner]

Romain Francoise <romain@orebokech.com> writes:

> This change is problematic for buffers where buffer-file-name is ""
> (like ERC server buffers in my case), file-name-directory returns nil so

Hi Romain, Stefan,

I can confirm this for ERC channel buffers as well, running with CVS
erc and consider this a bug just like Stefan.

Where is the use of "" as a value of buffer-file-name documented?

Best regards,

Adrian

> string-match signals an error.  It makes it impossible to quit Emacs
> (you need to kill all such buffers manually).

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: Slow access to files using UNC path

[Romain Francoise]

Adrian Aichner <adrian@xemacs.org> writes:

> Where is the use of "" as a value of buffer-file-name documented?

See the commit message for erc-log.el rev. 1.7:

| (erc-log-setup-logging): set buffer-file-name to "", as (basic-save-buffer)
|     will prompt for a buffer name before invoking hooks. the buffer-file-name
|     will be overridden by (erc-save-buffer-in-logs) anyway - the main danger
|     of doing this is write-file-contents hooks. Let's see if anyone complains.
| (erc-save-buffer-in-logs): return t, so that further write hooks are not run

The real problem is probably that buffer-file-name cannot be set in
advance to the correct value since the filename will often be based on
the date/time of saving.

CC'ing Damien for comments.

-- 
Romain Francoise <romain@orebokech.com> | And you never lay down and
it's a miracle -- http://orebokech.com/ | you never stay home...

Re: Slow access to files using UNC path

[Damien Elmes]

Romain Francoise <romain@orebokech.com> writes:

>> Where is the use of "" as a value of buffer-file-name documented?
>
> See the commit message for erc-log.el rev. 1.7:
>
> | (erc-log-setup-logging): set buffer-file-name to "", as (basic-save-buffer)
> |     will prompt for a buffer name before invoking hooks. the buffer-file-name
> |     will be overridden by (erc-save-buffer-in-logs) anyway - the main danger
> |     of doing this is write-file-contents hooks. Let's see if anyone complains.
> | (erc-save-buffer-in-logs): return t, so that further write hooks are not run
>
> The real problem is probably that buffer-file-name cannot be set in
> advance to the correct value since the filename will often be based on
> the date/time of saving.

When a buffer has no file name, basic-save-buffer will prompt the user
interactively for one. Since before-save-hook isn't run until after
the interactive request for a file name, this prevents a hook from
setting a file name based on external factors (such as the time),
without first requiring the user to input some junk data. The use of
"" was a hack to avoid prompting, since for ERC logging, the value of
buffer-file-name is ignored and computed by a routine instead.

Cheers,

Damien

Re: Slow access to files using UNC path

[Stefan]

> When a buffer has no file name, basic-save-buffer will prompt the user
> interactively for one.  Since before-save-hook isn't run until after
> the interactive request for a file name, this prevents a hook from
> setting a file name based on external factors (such as the time),
> without first requiring the user to input some junk data.  The use of
> "" was a hack to avoid prompting, since for ERC logging, the value of
> buffer-file-name is ignored and computed by a routine instead.

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.


        Stefan

Re: Slow access to files using UNC path

[Damien Elmes]

Stefan <monnier@iro.umontreal.ca> 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

Re: Slow access to files using UNC path

[Richard Stallman]

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


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: Slow access to files using UNC path

[Stefan]

> 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

Re: Slow access to files using UNC path

[Damien Elmes]

Stefan <monnier@iro.umontreal.ca> 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

Re: Slow access to files using UNC path

[Stefan Monnier]

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

Re: Slow access to files using UNC path

[Damien Elmes]

Stefan Monnier <monnier@iro.umontreal.ca> 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

Re: Slow access to files using UNC path

[Stefan]

>> 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: Slow access to files using UNC path

[Richard Stallman]

    > In Emacs, a 'path' is something like load-path, and we never use the
    > term 'path' for a directory name or file name.

Actually, that is a general GNU system convention.

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hi,
 Based on some inputs from dak/eliz and some extra digging into Elisp, I
 have the following version which can show good improvements in the
 behaviour from user point of view (in comparision wrt XEmacs).

I have this modified version in my _emacs file:
      ;; For faster opening of files with UNC path
      (defadvice find-file (before find-file-unc first activate)
        "Open file literally if UNC path for better performance"
        (let ((file (replace-regexp-in-string "\\\\" "/" (ad-get-arg
        0))))
          (if (string-match "^//" file)
              (cond ((find-file-literally file)
                     (set-auto-mode)))))) ; Guess the mode

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,
 I find accessing a file using UNC path using GNU Emacs (CVS Head, W2K
 and MinGW32 build) very slow when compared to XEmacs. Has anyone
 experienced the same and explored the reason?
 Since I work with computers on LAN, I frequently access files using UNC
 path and end up waiting for significant duration of time. Looking
 forward to see a solution for this problem.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Peter Lee]

>>>> Dhruva Krishnamurthy writes:

    Dhruva> Hello, I find accessing a file using UNC path using GNU
    Dhruva> Emacs (CVS Head, W2K and MinGW32 build) very slow when
    Dhruva> compared to XEmacs. Has anyone experienced the same and
    Dhruva> explored the reason?

I'm using mingw32 cvs build on XP and UNC access is very fast.  No
different actually than any other application.  Does it happen if you
start without an init file '-Q'?

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,

On Fri, 16 Jul 2004 08:22:01 -0500, "Peter Lee" <pete_lee@swbell.net>
said:
> >>>> Dhruva Krishnamurthy writes:
> 
>     Dhruva> Hello, I find accessing a file using UNC path using GNU
>     Dhruva> Emacs (CVS Head, W2K and MinGW32 build) very slow when
>     Dhruva> compared to XEmacs. Has anyone experienced the same and
>     Dhruva> explored the reason?
> 
> I'm using mingw32 cvs build on XP and UNC access is very fast.  No
> different actually than any other application.  Does it happen if you
> start without an init file '-Q'?

 I just realised that XEmacs does something like find-file-literally
 (and a little more, I guess). If I use find-file-literally in GNU
 Emacs, it is as fast as in XEmacs. I am using the following code in my
 .emacs (dot emacs).

      ;; For faster opening of files with UNC path
      (defadvice find-file (before find-file-unc first activate)
        "Insert an empty line when moving up from the top line."
        (let ((file (ad-get-arg 0)))
          (if (or (string-match "^//" file)
                  (string-match "^\\\\" file))
              (cond ((find-file-literally file)
                     (font-lock-fontify-buffer))))))

PS: Any improvements for the above code is welcome, I am an amature.
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

"Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:

>           (if (or (string-match "^//" file)
>                   (string-match "^\\\\" file))

            (if (string-match "^[/\\]" file)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:
> 
> >           (if (or (string-match "^//" file)
> >                   (string-match "^\\\\" file))
> 
>             (if (string-match "^[/\\]" file)

That's not the same.  The first matches either // or \ at the start
of a filename, the latter matches either / or \ at the start of a
filename.

I don't know the context, though: maybe the second actually was what
was desired.  Or maybe it was // or \\ in which case we'd need
(string-match "^\(//\|\\\\\\\\\)")

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Slow access to files using UNC path

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: 18 Jul 2004 04:31:54 +0200
> 
> That's not the same.  The first matches either // or \ at the start
> of a filename, the latter matches either / or \ at the start of a
> filename.
> 
> I don't know the context, though: maybe the second actually was what
> was desired.  Or maybe it was // or \\ in which case we'd need
> (string-match "^\(//\|\\\\\\\\\)")

AFAIK, Windows behaves the same no matter if you pass it a forward
slash or a backslash.  But a UNC _must_ start with two of them, so
"^[/\\]" is not good enough.  It should be "^[/\\][/\\]" or something
similar.

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,

On Sun, 18 Jul 2004 07:09:32 +0200, "Eli Zaretskii" <eliz@gnu.org> said:
> > From: David Kastrup <dak@gnu.org>
> > Date: 18 Jul 2004 04:31:54 +0200
> > 
> > That's not the same.  The first matches either // or \ at the start
> > of a filename, the latter matches either / or \ at the start of a
> > filename.
> > 
> > I don't know the context, though: maybe the second actually was what
> > was desired.  Or maybe it was // or \\ in which case we'd need
> > (string-match "^\(//\|\\\\\\\\\)")
> 
> AFAIK, Windows behaves the same no matter if you pass it a forward
> slash or a backslash.  But a UNC _must_ start with two of them, so
> "^[/\\]" is not good enough.  It should be "^[/\\][/\\]" or something
> similar.

It should match: "\\" or "//" , which is basically 2 forward/backward
slashes
In normal regexp: I would have used: ^(\\\\|//) or as dak suggested:
(string-match "^\(//\|\\\\\\\\\)")
This just does _not_ work.

Ex: (string-match "^\(//\|\\\\\\\\\)" "//wolfdei/d/users/_emacs") ;;
which is a UNC notation for a folder on host "wolfdei"
The above regexp fails to match. I am not sure whether this is Windoze
specific though.

Are there any reasons for not supporting PERL compatible regular
expressions (through PCRE)? IMHO, PERL has the best
regular expression support and is very widely used.

with best regards.
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

"Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:

> Are there any reasons for not supporting PERL compatible regular
> expressions (through PCRE)? IMHO, PERL has the best
> regular expression support and is very widely used.

Emacs regexps already have most of the features PERL regexps provide, only
with a slightly different syntax (more like BREs instead of EREs,
different set of special characters)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[Eli Zaretskii]

> Date: Sun, 18 Jul 2004 11:42:25 +0530
> From: "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm>
> > 
> > AFAIK, Windows behaves the same no matter if you pass it a forward
> > slash or a backslash.  But a UNC _must_ start with two of them, so
> > "^[/\\]" is not good enough.  It should be "^[/\\][/\\]" or something
> > similar.
> 
> It should match: "\\" or "//" , which is basically 2 forward/backward
> slashes

AFAIK, "/\" and "\/" produce the same result, which is why I said
"^[/\\][/\\]",

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Sun, 18 Jul 2004 21:41:13 +0200, "Eli Zaretskii" <eliz@gnu.org> said:
> > Date: Sun, 18 Jul 2004 11:42:25 +0530
> > From: "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm>
> > > 
> > > AFAIK, Windows behaves the same no matter if you pass it a forward
> > > slash or a backslash.  But a UNC _must_ start with two of them, so
> > > "^[/\\]" is not good enough.  It should be "^[/\\][/\\]" or something
> > > similar.
> > 
> > It should match: "\\" or "//" , which is basically 2 forward/backward
> > slashes
> 
> AFAIK, "/\" and "\/" produce the same result, which is why I said
> "^[/\\][/\\]",

This will also match a combination (2 nos) of forward and/or backword
slash which is not correct. It shouldeither be 2 forward slashes or 2
backword slashes.
Ex: A valid UNC can be either "//hostname/sharefolder/file" or
"\\hostname\sharefolder\file" (add extra backslash in Emacs)
and _not_ "/\hostname/sharefolder/file" ...

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Eli Zaretskii]

> Date: Mon, 19 Jul 2004 10:05:17 +0530
> From: "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm>
> 
> Ex: A valid UNC can be either "//hostname/sharefolder/file" or
> "\\hostname\sharefolder\file" (add extra backslash in Emacs)
> and _not_ "/\hostname/sharefolder/file" ...

To the best of my knowledge, "/\hostname/sharefolder/file" is also
treated as a UNC.  Windows canonicalizes the file names before it
passes them to the filesystem-related system calls, and as part of
that canonicalization every slash is converted to a backslash.

Re: Slow access to files using UNC path

[KOBAYASHI Yasuhiro]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

Maybe I found out the reason why slow access occured.

'(file-directory-p "//{arch}")' or '(file-directory-p "//MCVS/CVS")'
is executed in vc-arch-registered or vc-mcvs-registered
even though '{arch}' or 'MCVS' as computers dosen't exist.

So what about the following patch?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc --]
[-- Type: text/x-patch, Size: 1386 bytes --]

*** ~/src/emacs/current/lisp/vc-arch.el	Wed Aug 25 00:27:47 2004
--- ~/src/emacs/current/lisp/vc-arch.el.orig	Wed Aug 25 17:19:14 2004
***************
*** 76,81 ****
--- 76,83 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; Avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match "^\\(//\\|\\\\\\\\\\)$" dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "{arch}" dir))

*** c:/usr/emacs/current/lisp/vc-mcvs.el	Wed Aug 25 00:25:45 2004
--- c:/home/kobayays/src/emacs-ime/lisp/vc-mcvs.el	Wed Aug 25 17:19:52 2004
***************
*** 118,123 ****
--- 118,125 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match "^\\(//\\|\\\\\\\\\\)$" dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))

[-- Attachment #3: Type: text/plain, Size: 50 bytes --]


-- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,
 I applied the patch (manually as I do not have a patch utility on
 win32). It does not seem to make a difference to me. Let me explain the
 steps I followed.
1. I manually applied the on to the files
2. Byte compiled them
3. Re-started emacs and tried accessing the file in UNC (without my
defadvice hack)
4. It took the same time.

One observation I have made which might help in identifying the cause.
 When I open the file literally, it is real fast. As fast as opening a
 local file. When I change the mode (as per file contents, ex: If I open
 a C++ file, I change it to c++-mode) and _then_ try to _save_ the
 changes, it again takes a very long time.
 So, the time I save by opening a file literally is lost when I try to
 save the changes. If I open the same file as usual, I spend the long
 time while opening the file but saving is _fast_ (as for any local
 file).
 With this, I feel it is not something with search (as the patch seems
 to change). I may be wrong in my deduction, correct me if so.

with best regards,
dhruva

On Wed, 25 Aug 2004 18:44:08 +0900, "KOBAYASHI Yasuhiro"
<kobayays@otsukakj.co.jp> said:
> Maybe I found out the reason why slow access occured.
> 
> '(file-directory-p "//{arch}")' or '(file-directory-p "//MCVS/CVS")'
> is executed in vc-arch-registered or vc-mcvs-registered
> even though '{arch}' or 'MCVS' as computers dosen't exist.
> 
> So what about the following patch?
> 
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[KOBAYASHI Yasuhiro]

In message Re: Slow access to files using UNC path
 on Thu, 26 Aug 2004 10:06:07 +0530
 "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> wrote:

> Hello,
>  I applied the patch (manually as I do not have a patch utility on
>  win32). It does not seem to make a difference to me. Let me explain the
>  steps I followed.
> 1. I manually applied the on to the files
> 2. Byte compiled them
> 3. Re-started emacs and tried accessing the file in UNC (without my
> defadvice hack)
> 4. It took the same time.

'make bootstrap' is needed so that the patch effects the
autoload section.

> One observation I have made which might help in identifying the cause.
>  When I open the file literally, it is real fast. As fast as opening a
>  local file.

find-file-hook is set vc-find-file-hook by default and
finally vc-arch-registered or vc-mcvs-registered run.

find-file-literally does't hook it.

Easy way avoiding slow access without the patch is
(setq vc-handled-backends '(RCS CVS SVN SCCS)).
-- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,
On Thu, 26 Aug 2004 16:10:50 +0900, "KOBAYASHI Yasuhiro"
<kobayays@otsukakj.co.jp> said:
> In message Re: Slow access to files using UNC path
> Easy way avoiding slow access without the patch is
> (setq vc-handled-backends '(RCS CVS SVN SCCS)).

Wow! this works great. I am now able to see the behaviour I wanted to.
Opening and saving are as fast as it would be with any local file.
IMO, this patch _must_ get into GNU Emacs CVS soon so that all others
(if any) suffering from UNC path related performance issues will
benefit. Thank you for such an elegant and simple/clean fix.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Richard Stallman]

Does any further change need to be installed in Emacs itself
to get good results on this issue?

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]


On Thu, 26 Aug 2004 16:52:47 -0400, "Richard Stallman" <rms@gnu.org>
said:
> Does any further change need to be installed in Emacs itself
> to get good results on this issue?

I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
'make bootstrap', it did not work for me. I suspect the pattern match
for a UNC path (which can be both combinations of back/forward slashes). 
The fix in my .emacs file as: (setq vc-handled-backends '(RCS CVS SVN
SCCS)) as suggested by the author does work. I therefore feel his
analysis is correct. I request the patch author to confirm this (in CC).

PS: I am attaching the patch sent by the author for reference only (no
way trying to take credit).

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc.patch --]
[-- Type: text/x-patch; name="vc.patch", Size: 1386 bytes --]

*** ~/src/emacs/current/lisp/vc-arch.el	Wed Aug 25 00:27:47 2004
--- ~/src/emacs/current/lisp/vc-arch.el.orig	Wed Aug 25 17:19:14 2004
***************
*** 76,81 ****
--- 76,83 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; Avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match "^\\(//\\|\\\\\\\\\\)$" dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "{arch}" dir))

*** c:/usr/emacs/current/lisp/vc-mcvs.el	Wed Aug 25 00:25:45 2004
--- c:/home/kobayays/src/emacs-ime/lisp/vc-mcvs.el	Wed Aug 25 17:19:52 2004
***************
*** 118,123 ****
--- 118,125 ----
  ;;;###autoload     (while (and (stringp dir)
  ;;;###autoload                 (not (equal
  ;;;###autoload                       dir (setq dir (file-name-directory dir))))
+ ;;;###autoload                 ;; avoid searching no existing computer on Windowz.
+ ;;;###autoload                 (not (string-match "^\\(//\\|\\\\\\\\\\)$" dir))
  ;;;###autoload                 dir)
  ;;;###autoload       (setq dir (if (file-directory-p
  ;;;###autoload                      (expand-file-name "MCVS/CVS" dir))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Slow access to files using UNC path

[Stefan Monnier]

> I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
> 'make bootstrap', it did not work for me. I suspect the pattern match

The patch is basically "right", but only fixes one of the two (i.e. 2 of
the 4) places.  Also I think the problem is not limited to UNC paths, but
might apply to any "global network filesystem" such as AFS, but also
NFS via /net.  So maybe we should add a setting like

        (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/")

What do people think?


        Stefan

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On 27 Aug 2004 09:19:03 -0400, "Stefan Monnier"
<monnier@iro.umontreal.ca> said:
> > I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
> > 'make bootstrap', it did not work for me. I suspect the pattern match
> 
> The patch is basically "right", but only fixes one of the two (i.e. 2 of
> the 4) places.  Also I think the problem is not limited to UNC paths, but
> might apply to any "global network filesystem" such as AFS, but also
> NFS via /net.  So maybe we should add a setting like
> 
>         (defvar vc-hostname-fs-path-re
>         "\\`\\([\\/][\\/]\\|/net/\\|/afs/")
> 
> What do people think?

When I use the above regexp in the earlier patch and try to open file:
"//wolfdei/d/users/dhruva/_emacs", I get the following error:
not: Invalid regexp: "Unmatched ( or \\("

I am not good in GNU Emacs regexp to fix this. If we have a working
solution for this, I will be looking forward to having the patch (with
the above mentioned changes) in main stream.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,

On 27 Aug 2004 09:19:03 -0400, "Stefan Monnier"
<monnier@iro.umontreal.ca> said:
> > I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
> > 'make bootstrap', it did not work for me. I suspect the pattern match
> 
> The patch is basically "right", but only fixes one of the two (i.e. 2 of
> the 4) places.  Also I think the problem is not limited to UNC paths, but
> might apply to any "global network filesystem" such as AFS, but also
> NFS via /net.  So maybe we should add a setting like
> 
>         (defvar vc-hostname-fs-path-re
>         "\\`\\([\\/][\\/]\\|/net/\\|/afs/")
> 

May be this was the regexp intended:
(defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\)\\|/net/\\|/afs/")

This works for me (tested for UNC only). I made a change to the patch to
use the variable "vc-hostname-fs-path-re" and added the defvar in my
.emacs (this can be moved into the lower level elisp code). Maybe, we
can allow this to be customized by advanced users (defcustom).

-dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

"Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:

G> Hello,
>
> On 27 Aug 2004 09:19:03 -0400, "Stefan Monnier"
> <monnier@iro.umontreal.ca> said:
>> > I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
>> > 'make bootstrap', it did not work for me. I suspect the pattern match
>> 
>> The patch is basically "right", but only fixes one of the two (i.e. 2 of
>> the 4) places.  Also I think the problem is not limited to UNC paths, but
>> might apply to any "global network filesystem" such as AFS, but also
>> NFS via /net.  So maybe we should add a setting like
>> 
>>         (defvar vc-hostname-fs-path-re
>>         "\\`\\([\\/][\\/]\\|/net/\\|/afs/")
>> 
>
> May be this was the regexp intended:
> (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\)\\|/net/\\|/afs/")

Try this instead:

(defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

On Mon, 30 Aug 2004 10:32:16 +0200, "Andreas Schwab" <schwab@suse.de>
said:
> "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:
> 
> G> Hello,
> >
> > On 27 Aug 2004 09:19:03 -0400, "Stefan Monnier"
> > <monnier@iro.umontreal.ca> said:
> >> > I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a
> >> > 'make bootstrap', it did not work for me. I suspect the pattern match
> >> 
> >> The patch is basically "right", but only fixes one of the two (i.e. 2 of
> >> the 4) places.  Also I think the problem is not limited to UNC paths, but
> >> might apply to any "global network filesystem" such as AFS, but also
> >> NFS via /net.  So maybe we should add a setting like
> >> 
> >>         (defvar vc-hostname-fs-path-re
> >>         "\\`\\([\\/][\\/]\\|/net/\\|/afs/")
> >> 
> >
> > May be this was the regexp intended:
> > (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\)\\|/net/\\|/afs/")
> 
> Try this instead:
> 
> (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")
> 

After applying the patch, I do a 'make bootstrap' and I get an error
reporting "vc-hostname-fs-path-re" not found. It is because, the patch
alters the autoloads and the variable is not defined when the function
(in the patch) is autoloaded. How/where do we need to add the above
variable definition (defvar)?

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: Slow access to files using UNC path

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:
>> 
>> >           (if (or (string-match "^//" file)
>> >                   (string-match "^\\\\" file))
>> 
>>             (if (string-match "^[/\\]" file)
>
> That's not the same.  The first matches either // or \ at the start
> of a filename, the latter matches either / or \ at the start of a
> filename.

You're right.

> I don't know the context, though: maybe the second actually was what
> was desired.  Or maybe it was // or \\ in which case we'd need
> (string-match "^\(//\|\\\\\\\\\)")

Still not enough backslashes:

  (string-match "^\\(//\\|\\\\\\\\\\)" file)

Remember that there are two levels of quoting: regexp quoting and string
quoting, each adding it's own batch of backslashes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Slow access to files using UNC path

[Dhruva Krishnamurthy]

Hello,

On Sun, 18 Jul 2004 11:49:12 +0200, "Andreas Schwab" <schwab@suse.de>
said:
> David Kastrup <dak@gnu.org> writes:
> > I don't know the context, though: maybe the second actually was what
> > was desired.  Or maybe it was // or \\ in which case we'd need
> > (string-match "^\(//\|\\\\\\\\\)")
> 
> Still not enough backslashes:
> 
>   (string-match "^\\(//\\|\\\\\\\\\\)" file)
> 
> Remember that there are two levels of quoting: regexp quoting and string
> quoting, each adding it's own batch of backslashes.

This (adding extra backslashes) is the main reason for all confusion. I
personally feel PERL regex is more cleaner.
 Anyway, thanks a lot for the help in Emacs regexp, I can now work with
 GNU Emacs to access files using
UNC paths. I wish the code snippet I had sent could be added as a
customizable feature so that all
packages wanting to access files can use it. Maybe packages uses a much
lower method to access files
and they are not facing these issues.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/