bug in edit.m

[John W. Eaton]

On 15-Jan-2008, Ben Abbott wrote:

| 
| On Jan 15, 2008, at 7:12 PM, John W. Eaton wrote:
| 
| > On 15-Jan-2008, Ben Abbott wrote:
| >
| > | Actually, I guess I'd prefer all cases be left to the editor to  
| > decide
| > | what to do.
| >
| > In that case, you would just always pass the filename (whatever it is,
| > presumably after looking for it in the path if it is not an absolute
| > file name) and let the editor have its way.  Then we wouldn't need to
| > worry about FUNCTION.HOME or opening in the current directory, or
| > permissions or anything else.
| >
| > jwe
| 
| Something like the sequence below?
| 
| (1) Search the path for the explicit file (do not append .m)
| (2) If no file, the append the ".m" and search again.
| (3) if file exists in the path, append its path to the filename.
| (4) Pass the result to the editor.

OK, how about the following (here, F is the given file name):

  files = {f};
  if (isempty (regexp (f, "\\.m$")))
    files{2} = strcat (f, ".m");
  endif
  file_to_edit = file_in_loadpath (files);
  if (isempty (file_to_edit))
    file_to_edit = f;
  endif

If we are searching for foo and foo.m, the above will only search the
path once, looking in each directory for foo first, then for foo.m,
returning the first one found.

Except that you might want to deal with absolute or rooted relative
file names first.  There are internal functions in Octave that decide
whether a file name is absolute or rooted relative (declared in
liboctave/oct-env.h), but they are not exported to the scripting
language.  Maybe they should be.  Or maybe it would be better to fix
file_in_loadpath to properly handle absolute and rooted relative
names.

Also, if a user asks to edit foo.dat, should we avoid looking for
foo.dat.m? In that case, I guess the pattern match should just be to
see if there is a "." anywhere in the name.

jwe