find-file-literally-at-point

[Edward O'Connor]

Hi,

I recently found myself in need of such a function (I was going through
a bunch of files to strip out their UTF-8 BOMs, if you're curious), and
it was quick enough to put together:

(autoload 'ffap-guesser "ffap")
(defun find-file-literally-at-point ()
  "Open the file at point (like `ffap') with `find-file-literally'."
  (interactive)
  (find-file-literally (ffap-guesser)))

Is this something people might like to see added to ffap.el? I've signed
papers.


Thanks,
Ted

[Juri Linkov]

> I recently found myself in need of such a function (I was going through
> a bunch of files to strip out their UTF-8 BOMs, if you're curious),

Oh, I see.  That's what I regularly had to do on files produced
by Windows editors :)  Some time ago Emacs used to display BOMs,
so it was easy to see and delete BOMs, but now doesn't anymore,
since now the default coding system of files with the BOM is
`utf-8-with-signature'.  Forcing it to use `utf-8' with e.g.
`C-x RET c utf-8 RET C-x C-f' is a way to display BOMs
in an UTF-8 file.

> and it was quick enough to put together:
>
> (autoload 'ffap-guesser "ffap")
> (defun find-file-literally-at-point ()
>   "Open the file at point (like `ffap') with `find-file-literally'."
>   (interactive)
>   (find-file-literally (ffap-guesser)))
>
> Is this something people might like to see added to ffap.el?

When I added a few find-file related functions to ffap,
I don't remember why I missed `find-file-literally'.
Maybe because it has no keybinding (should we try to find one?).
So we definitely need such a function.

However, I wonder why you don't implement it using `ffap-file-finder'
and `call-interactively', like e.g. `ffap-alternate-file' does?
Like other ffap functions, it asks for a filename in the minibuffer,
and allows to get the default behavior with C-u.

--
Juri Linkov
http://www.jurta.org/emacs/

[Stefan Monnier]

> When I added a few find-file related functions to ffap,
> I don't remember why I missed `find-file-literally'.
> Maybe because it has no keybinding (should we try to find one?).
> So we definitely need such a function.

BTW, I'd be interested in trying to integrate the FFAP behavior into the
default find-file behavior.  If you people have ideas how such an
integration could take place, I'm all ears (of course, backward
compatibility with older users is very important).  Maybe we could have
an FFAP prefix, so <prefix> C-x C-f would `find-file-at-point'.
Or maybe we could have a keybinding in
minibuffer-local-filename-completion-map to bring in the
filename-at-point.


        Stefan

[Miles Bader-2]

Stefan Monnier <monnier@...> writes:
> Or maybe we could have a keybinding in
> minibuffer-local-filename-completion-map to bring in the
> filename-at-point.

That sounds most useful to me -- it seems more flexible for users, and
it could immediately be used with (almost) all functions that want
filename entry.

-Miles

--
Hers, pron. His.

[Juri Linkov]

>> When I added a few find-file related functions to ffap,
>> I don't remember why I missed `find-file-literally'.
>> Maybe because it has no keybinding (should we try to find one?).
>> So we definitely need such a function.
>
> BTW, I'd be interested in trying to integrate the FFAP behavior into the
> default find-file behavior.  If you people have ideas how such an
> integration could take place, I'm all ears (of course, backward
> compatibility with older users is very important).

I had an idea for a long time how to do such an integration, but
not implemented it yet because I currently don't see how to do this
without loading the whole ffap.el by default.  Perhaps we should
rewrite most of the ffap functionality and simplify it.

The idea is to put a file/URL from the text around the point into
the minibuffer's default values list.  So typing `C-x C-f M-n'
on a file name will bring in it from the current buffer into the
minibuffer.  This is useful for all prompts that read files or
directories.  For instance, `M-x mkdir RET M-n' will try to fetch
the directory name from the current buffer, and so on.

> Or maybe we could have a keybinding in
> minibuffer-local-filename-completion-map to bring in the
> filename-at-point.

`M-n' is such a binding that users are already familiar with.
If it turns out that it's unsuitable, we could invent a new one.

--
Juri Linkov
http://www.jurta.org/emacs/

[Eli Zaretskii]

> From: Juri Linkov <juri@...>
> Date: Fri, 06 Nov 2009 06:45:45 +0200
> Cc: Edward O'Connor <hober0@...>, emacs-devel@...
>
> The idea is to put a file/URL from the text around the point into
> the minibuffer's default values list.  So typing `C-x C-f M-n'
> on a file name will bring in it from the current buffer into the
> minibuffer.

That's fine, but I don't think it should be the only possibility.  We
should also provide a special key binding just for ffap, and if
possible also an explicit prompt or tooltip for it.

The reason is that I think we already have too many unintuitive
features in minibuffer prompts, that may be working well for Emacs
veterans, but are entirely concealed (by virtue of their unintuitive
behavior) from the rest.  `M-n' is one such unintuitive feature.

[Eduard Wiebe]

"Edward O'Connor" <hober0@...> writes:

> Hi,
>
> I recently found myself in need of such a function (I was going through
> a bunch of files to strip out their UTF-8 BOMs, if you're curious), and
> it was quick enough to put together:

I need/use `find-fil-literaly' often from dired. For this purpose i have

(define-key dired-mode-map (kbd "<C-return>")
  (lambda ()
    (interactive)
    (find-file-literally (dired-get-file-for-visit))))

in my .emacs.

--
Eduard Wiebe

[Juri Linkov]

>> The idea is to put a file/URL from the text around the point into
>> the minibuffer's default values list.  So typing `C-x C-f M-n'
>> on a file name will bring in it from the current buffer into the
>> minibuffer.
>
> That's fine, but I don't think it should be the only possibility.  We
> should also provide a special key binding just for ffap, and if
> possible also an explicit prompt or tooltip for it.

We already have a special menu `Minibuf' for the minibuffer, so we
could add more minibuffer-related items to unconceal minibuffer
functionality.

--
Juri Linkov
http://www.jurta.org/emacs/

[Stefan Monnier]

> I had an idea for a long time how to do such an integration, but
> not implemented it yet because I currently don't see how to do this
> without loading the whole ffap.el by default.  Perhaps we should
> rewrite most of the ffap functionality and simplify it.

By "integration" I mostly mean the functionality, not necessarily
the code.  But if it means preloading ffap.el, that's not necessarily
a bad thing, although I think that by integrating it, we can make it
a lot simpler, so I expect that a complete rewrite will be preferable
(especially since we probably wouldn't provide every single last detail
of ffap's functionality).

> The idea is to put a file/URL from the text around the point into
> the minibuffer's default values list.  So typing `C-x C-f M-n'
> on a file name will bring in it from the current buffer into the
> minibuffer.

I thought about it but M-n is already used in some file prompts for
other purposes, so the user would then have to hit M-n more than once to
get the file-at-point, which makes it cumbersome.  I think a dedicated
keybinding would be better.

BTW, another possibility is to do what complete.el does: use a special
file name (complete.el uses "<>" but we could choose something else,
like " ") to mean file-at-point.  I think it's a worse solution (both
because it may collide with a real file name, and more importantly
because it makes it impossible/difficult to edit the file-at-point), but
I throw it out, for completeness's sake.


        Stefan

[Stefan Monnier]

>> Or maybe we could have a keybinding in
>> minibuffer-local-filename-completion-map to bring in the
>> filename-at-point.

> That sounds most useful to me -- it seems more flexible for users, and
> it could immediately be used with (almost) all functions that want
> filename entry.

Another advantage is that minibuffer-local-filename-completion-map is
not nearly as crowded as the global map.  But still, we'd have to come
up with a good binding.


        Stefan

[Juri Linkov]

> By "integration" I mostly mean the functionality, not necessarily
> the code.  But if it means preloading ffap.el, that's not necessarily
> a bad thing, although I think that by integrating it, we can make it
> a lot simpler, so I expect that a complete rewrite will be preferable
> (especially since we probably wouldn't provide every single last detail
> of ffap's functionality).

I forgot that we already have a clean and small counterpart of ffap
that can be preloaded instead of ffap.el.  It is thingatpt.el.
With (thing-at-point 'filename) it returns the filename at point,
and with (thing-at-point 'url) it returns the URL at point.

>> The idea is to put a file/URL from the text around the point into
>> the minibuffer's default values list.  So typing `C-x C-f M-n'
>> on a file name will bring in it from the current buffer into the
>> minibuffer.
>
> I thought about it but M-n is already used in some file prompts for
> other purposes,

Let's see what currently M-n does in file prompts (0. means the default
input, and 1. - the minibuffer's content after one M-n):

`C-x C-f' in a non-file buffer:
0. current directory name

`C-x C-f' in a file buffer:
0. current directory name
1. file name of the current buffer

`C-x C-v' in a file buffer:
0. file name of the current buffer
1. file name of the current buffer
(the last case has duplicates)

> so the user would then have to hit M-n more than once to get the
> file-at-point, which makes it cumbersome.

After adding a file name at point:

`C-x C-f' in a non-file buffer:
0. current directory name
1. file name at point

`C-x C-f' in a file buffer:
0. current directory name
1. file name of the current buffer
2. file name at point

`C-x C-v' in a file buffer:
0. file name of the current buffer
1. file name at point

So M-n more than once is only in a file buffer,
where we could add a file name at point before
the file name of the current buffer:

`C-x C-f' in a file buffer:
0. current directory name
1. file name at point
2. file name of the current buffer

> I think a dedicated keybinding would be better.

Of course, a dedicated keybinding would be good as well.
IIRC, the last time this has been discussed where Drew
proposed `M-.' to yank text at point into the minibuffer in:
http://thread.gmane.org/gmane.emacs.devel/50372

--
Juri Linkov
http://www.jurta.org/emacs/

[Stefan Monnier]

>> By "integration" I mostly mean the functionality, not necessarily
>> the code.  But if it means preloading ffap.el, that's not necessarily
>> a bad thing, although I think that by integrating it, we can make it
>> a lot simpler, so I expect that a complete rewrite will be preferable
>> (especially since we probably wouldn't provide every single last detail
>> of ffap's functionality).
> I forgot that we already have a clean and small counterpart of ffap
> that can be preloaded instead of ffap.el.  It is thingatpt.el.
> With (thing-at-point 'filename) it returns the filename at point,
> and with (thing-at-point 'url) it returns the URL at point.

I think it'd be important to make it mode-aware, so that when you're on
a (require 'foo) or on a #include "bar", it can find the relevant file.
So (thing-at-point 'filename) wouldn't quite cut it as it stands.


        Stefan

[MON KEY]

> I forgot that we already have a clean and small counterpart of ffap
> that can be preloaded instead of ffap.el.  It is thingatpt.el.
> With (thing-at-point 'filename) it returns the filename at point,
> and with (thing-at-point 'url) it returns the URL at point.

Currently (thing-at-point 'url) will not reliably return the URL at point in a
good deal of corner cases; URL's containing `,' being a good case in point.

s_P

[Juri Linkov]

> When I added a few find-file related functions to ffap,
> I don't remember why I missed `find-file-literally'.
> Maybe because it has no keybinding (should we try to find one?).
> So we definitely need such a function.

Below is a patch that implements `ffap-literally' using
`ffap-file-finder' and `call-interactively' like other similar
functions do.  It also adds `ffap-alternate-file-other-window' -
the remaining missing find-file related function that has
no keybinding.

Index: lisp/ffap.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/ffap.el,v
retrieving revision 1.86
diff -c -r1.86 ffap.el
*** lisp/ffap.el 2 Oct 2009 03:48:40 -0000 1.86
--- lisp/ffap.el 9 Nov 2009 00:39:51 -0000
***************
*** 1435,1441 ****
    (string-match ffap-dired-wildcards filename)
    find-file-wildcards
    ;; Check if it's find-file that supports wildcards arg
!   (memq ffap-file-finder '(find-file find-alternate-file)))
        (funcall ffap-file-finder (expand-file-name filename) t))
       ((or (not ffap-newfile-prompt)
   (file-exists-p filename)
--- 1435,1443 ----
    (string-match ffap-dired-wildcards filename)
    find-file-wildcards
    ;; Check if it's find-file that supports wildcards arg
!   (memq ffap-file-finder '(find-file
!    find-alternate-file
!    find-alternate-file-other-window)))
        (funcall ffap-file-finder (expand-file-name filename) t))
       ((or (not ffap-newfile-prompt)
   (file-exists-p filename)
***************
*** 1708,1713 ****
--- 1710,1729 ----
    (let ((ffap-file-finder 'find-alternate-file))
      (call-interactively 'ffap)))
 
+ (defun ffap-alternate-file-other-window ()
+   "Like `ffap' and `find-alternate-file-other-window'.
+ Only intended for interactive use."
+   (interactive)
+   (let ((ffap-file-finder 'find-alternate-file-other-window))
+     (call-interactively 'ffap)))
+
+ (defun ffap-literally ()
+   "Like `ffap' and `find-file-literally'.
+ Only intended for interactive use."
+   (interactive)
+   (let ((ffap-file-finder 'find-file-literally))
+     (call-interactively 'ffap)))
+
  
  ;;; Bug Reporter:

--
Juri Linkov
http://www.jurta.org/emacs/

[Juri Linkov]

>> I forgot that we already have a clean and small counterpart of ffap
>> that can be preloaded instead of ffap.el.  It is thingatpt.el.
>> With (thing-at-point 'filename) it returns the filename at point,
>> and with (thing-at-point 'url) it returns the URL at point.
>
> I think it'd be important to make it mode-aware, so that when you're on
> a (require 'foo) or on a #include "bar", it can find the relevant file.
> So (thing-at-point 'filename) wouldn't quite cut it as it stands.

FFAP is already mode-aware, but IMHO its code is ugly.  It puts
all supported modes into `ffap-alist'.  Maybe we should reimplement
this in `thing-at-point' exposing a generic interface for modes
to be able to add their mode-specific settings (like e.g. imenu does
with `imenu-generic-expression').

--
Juri Linkov
http://www.jurta.org/emacs/

[Juri Linkov]

> I need/use `find-fil-literaly' often from dired. For this purpose i have
>
> (define-key dired-mode-map (kbd "<C-return>")
>   (lambda ()
>     (interactive)
>     (find-file-literally (dired-get-file-for-visit))))
>
> in my .emacs.

Maybe a prefix argument of `find-file' and `dired-find-file'
could be used to request `find-file-literally'.

--
Juri Linkov
http://www.jurta.org/emacs/

[Juri Linkov]

> Currently (thing-at-point 'url) will not reliably return the URL at point in a
> good deal of corner cases; URL's containing `,' being a good case in point.

Like URL part of `ffap-string-at-point-mode-alist', it counterpart
`thing-at-point-url-path-regexp' contains `,' as well.  Indeed,
calling (thing-at-point 'url) on an URL with `,' like
"http://www.google.com/search?q=foo,bar" returns the complete URL.
Perhaps there are other differences, but the comma case seems to be
the same in both.

--
Juri Linkov
http://www.jurta.org/emacs/

[Miles Bader-2]

Juri Linkov <juri@...> writes:
> Below is a patch that implements `ffap-literally' using

`ffap-literally' seems like the most horrible name ever tho...

-Miles

--
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere
islands of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

[Juri Linkov]

>> Below is a patch that implements `ffap-literally' using
>
> `ffap-literally' seems like the most horrible name ever tho...

There are two naming conventions in ffap.el: one where the function name
ends with the `-at-point' suffix, and another where the function name
begins with the `ffap-' prefix.

The problem with adding the `-at-point' suffix is that it will create
more horrible names than using the `ffap-' prefix.  Currently
the `-at-point' suffix is used only for relatively short names like
`find-file-at-point' and `dired-at-point'.  But using it for other
names will create names like `find-file-read-only-other-window-at-point'
(41 characters!) instead of the current `ffap-read-only-other-window'
(27 characters).

That's because the name `ffap' compresses 18 characters of
`find-file-at-point' into 4 characters of `ffap'.


--
Juri Linkov
http://www.jurta.org/emacs/

[Stefan Monnier]

> FFAP is already mode-aware, but IMHO its code is ugly.  It puts
> all supported modes into `ffap-alist'.  Maybe we should reimplement
> this in `thing-at-point' exposing a generic interface for modes
> to be able to add their mode-specific settings (like e.g. imenu does
> with `imenu-generic-expression').

That sounds like a good way to attack the problem, yes.


        Stefan