Re: FFAP

Re: FFAP

[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

Re: FFAP

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

Re: FFAP

[MON KEY]

On Sun, Nov 8, 2009 at 7:56 PM, Juri Linkov <juri@jurta.org> wrote:
>> 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.

Yes. You are correct. I am mistaking `thing-at-point' w/
`url-get-url-at-point' and var `url-get-url-filename-chars'
which do fail. Sorry for the noise.

,---- :FILE /url/url-util.el
| (eval-and-compile
|   (defvar url-get-url-filename-chars "-%.?@a-zA-Z0-9()_/:~=&"
|     "Valid characters in a URL."))
`----

(require 'url-util)
Then evaluate `url-get-url-at-point' for following:

http://www.google.com/search?q=foo,bar
http://www.vintagefashionguild.org/component/option,com_alphacontent/section,6/cat,59/task,view/id,496/Itemid,100/
http://apex.oracle.com/pls/otn/f?p=2400:1001:3681485306497103::NO::F2400_P1001_BACK_PAGE,F2400_P1001_PUB_MAIL_ID:1010,77177

:SEE-ALSO Sam Steingold's function `get-quotes-pf' with commented
gripes pertaining `,' in URL's:
(URL `http://clocc.cvs.sourceforge.net/*checkout*/clocc/clocc/src/cllib/gq.lisp')

>
>Juri Linkov
s_P

Re: FFAP

[Juri Linkov]

>> 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.
>
> Yes. You are correct. I am mistaking `thing-at-point' w/
> `url-get-url-at-point' and var `url-get-url-filename-chars'
> which do fail. Sorry for the noise.

So this is a third package to get an URL at point :)

> ,---- :FILE /url/url-util.el
> | (eval-and-compile
> |   (defvar url-get-url-filename-chars "-%.?@a-zA-Z0-9()_/:~=&"
> |     "Valid characters in a URL."))
> `----

Let's compare allowed URL characters for all of them:

ffap        "--:=&?$+@-Z_[:alpha:]~#,%;*"
thingatpt   "[^]\t\n \"'<>[^`{}]*[^]\t\n \"'<>[^`{}.,;]+"
url-util    "-%.?@a-zA-Z0-9()_/:~=&"

> Then evaluate `url-get-url-at-point' for following:
>
> http://www.vintagefashionguild.org/component/option,com_alphacontent/section,6/cat,59/task,view/id,496/Itemid,100/

This URL is from Joomla that uses commas to separate keywords.
Commas are also frequent in Drupal where they separate tags.
So I think a comma should be added to `url-get-url-filename-chars'.

> :SEE-ALSO Sam Steingold's function `get-quotes-pf' with commented
> gripes pertaining `,' in URL's:
> (URL `http://clocc.cvs.sourceforge.net/*checkout*/clocc/clocc/src/cllib/gq.lisp')

`,' in URLs are very common nowadays.

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

Re: FFAP

[Stefan Monnier]

>> Yes. You are correct. I am mistaking `thing-at-point' w/
>> `url-get-url-at-point' and var `url-get-url-filename-chars'
>> which do fail. Sorry for the noise.

> So this is a third package to get an URL at point :)

If someone could consolidate those 3 into a single function, that would
be appreciated.


        Stefan

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

Re: find-file-literally-at-point

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

FFAP (was: find-file-literally-at-point)

[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

Re: FFAP

[Miles Bader]

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

Re: FFAP

[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

Re: FFAP

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

Re: FFAP

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 06 Nov 2009 06:45:45 +0200
> Cc: Edward O'Connor <hober0@gmail.com>, emacs-devel@gnu.org
> 
> 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.

Re: FFAP

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

Re: FFAP

[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

Re: FFAP

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

Re: FFAP

[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

Re: FFAP

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

Re: FFAP

[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

ffap

[Richard Stallman]

I have got no response from the maintainer of ffap.el,
mic@mathcs.emory.edu, for many months.  Would anyone else
like to maintain it?