systemd @ in filenames not supported by thing-at-point

systemd @ in filenames not supported by thing-at-point

[Emanuel Berg]

I have this function to get to a file which is
a path in a buffer:

(defun find-file-at-line (&optional other-window)
  (interactive "P")
  (let ((possible-filename (thing-at-point 'filename t)) ; NO-PROPERTIES
        (find-fun
         (if other-window #'find-file-other-window #'find-file)) )
    (if (and possible-filename (file-exists-p possible-filename))
          (apply find-fun (list possible-filename))
      (progn
        (forward-char 1)
        (find-file-at-line) ))))

As you see, it relies on `thing-at-point' and
"filename".

However, with the lambasted systemd, files are
sometimes include an "@", as in

    /lib/systemd/system/getty@.service

I just now noticed that my function, or rather
`thing-at-point', breaks on such paths because
of this setting:

    (defvar thing-at-point-file-name-chars "-~/[:alnum:]_.${}#%,:"
      "Characters allowable in filenames.")

(line 241 in /usr/share/emacs/24.4/lisp/thingatpt.el.gz )

Because "@" isn't included, it is considered
a file name delimiter and the path returned is
incorrectly /lib/systemd/system/getty - with this:

    (setq thing-at-point-file-name-chars "@-~/[:alnum:]_.${}#%,:")

it works as expected.

But I don't know if that will break something else?

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 64 Blogomatic articles -                   

RE: systemd @ in filenames not supported by thing-at-point

[Drew Adams]

> However, with the lambasted systemd, files are
> sometimes include an "@", as in
>     /lib/systemd/system/getty@.service
> 
> I just now noticed that my function, or rather
> `thing-at-point', breaks on such paths because
> of this setting:
>     (defvar thing-at-point-file-name-chars "-~/[:alnum:]_.${}#%,:"
>       "Characters allowable in filenames.")
> 
> Because "@" isn't included, it is considered
> a file name delimiter and the path returned is
> incorrectly /lib/systemd/system/getty - with this:
> 
>     (setq thing-at-point-file-name-chars "@-~/[:alnum:]_.${}#%,:")
> it works as expected.
> But I don't know if that will break something else?

Looking at the code, it shouldn't break anything.  What's more,
I'd say that this variable should be a user option.  For one
thing, that would make clear to users that it won't break
anything to change the value. ;-)

Re: systemd @ in filenames not supported by thing-at-point

[Emanuel Berg]

Drew Adams wrote:

> Looking at the code, it shouldn't break
> anything. What's more, I'd say that this
> variable should be a user option. For one
> thing, that would make clear to users that it
> won't break anything to change the value. ;-)

... what do you mean?

In general, of course it can be broken by
setting the variable to something that isn't
consistent with the human/computer notion of
what is a filename.

Specifically, the present value is already
broken with respect to these filenames, for
example:

    $ cd /lib/systemd/system
    $ ls | grep @
    autovt@.service
    container-getty@.service
    getty@.service
    ifup@.service
    saned@.service
    serial-getty@.service
    ssh@.service
    systemd-backlight@.service
    systemd-fsck@.service
    systemd-nspawn@.service
    systemd-rfkill@.service
    usb_modeswitch@.service
    user@.service

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 64 Blogomatic articles -                   

RE: systemd @ in filenames not supported by thing-at-point

[Drew Adams]

> > Looking at the code, it shouldn't break
> > anything. What's more, I'd say that this
> > variable should be a user option. For one
> > thing, that would make clear to users that it
> > won't break anything to change the value. ;-)
> 
> ... what do you mean?

It won't break anything to change the value.

Using a value that doesn't get you the filename syntax
you want is not breaking anything.  Use whatever string
you want - you won't break anything (AFAICT).  Whether
a given string gives you the filename-grabbing behavior
you want/need is another story.

You had already determined that your change gave you
the filename-recognizing behavior you wanted.  Your
question was whether making that change might break
something.  My answer was that it doesn't look like it.
It is used only right there.  I don't see any other code
that depends on that variable value.  That variable is
used only to pick up a filename at point.  You cannot
break anything (AFAICT) by changing it to recognize
something different - another sort of filename or the
name of your uncle.

Re: systemd @ in filenames not supported by thing-at-point

[Stefan Monnier]

>> (defvar thing-at-point-file-name-chars "-~/[:alnum:]_.${}#%,:"
[...]
>> (setq thing-at-point-file-name-chars "@-~/[:alnum:]_.${}#%,:")

"@-~" matches all chars between @ and ~.
IOW it's important to keep the "-" as the first character.


        Stefan

Re: systemd @ in filenames not supported by thing-at-point

[Emanuel Berg]

Stefan Monnier wrote:

>> (setq thing-at-point-file-name-chars
>> "@-~/[:alnum:]_.${}#%,:")
>
> "@-~" matches all chars between @ and ~.
> IOW it's important to keep the "-" as the
> first character.

Which is 64-126?

Wow, that is low tech!

I suppose it can be useful for people wanting
higher precision than the char classes give but
still has too big a set of chars to input them
manually - ... or is it something else?

There is something similar in zsh I now
remember and I actually had a bug just like
this adding a char to a string without noticing
the second char (and had I, I don't think that
would have helped as it is just another dash) -
perhaps one should memorize to always "stack"
chars from the right (the tail) and not the
left (the head)?

By the way who has all that crazy stuff
in filenames? Even tho it might make sense to
add the @ perhaps one should not do it as
a political statement, and then have them
others removed as well...

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 64 Blogomatic articles -                   

Re: systemd @ in filenames not supported by thing-at-point

[Yuri Khan]

On Sat, Jul 30, 2016 at 8:31 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

>     (defvar thing-at-point-file-name-chars "-~/[:alnum:]_.${}#%,:"
>       "Characters allowable in filenames.")
>
> (line 241 in /usr/share/emacs/24.4/lisp/thingatpt.el.gz )
>
> Because "@" isn't included, it is considered
> a file name delimiter and the path returned is
> incorrectly /lib/systemd/system/getty - with this:
>
>     (setq thing-at-point-file-name-chars "@-~/[:alnum:]_.${}#%,:")
>
> it works as expected.
>
> But I don't know if that will break something else?

User expectations, mostly.

As you surely know, on *nix, every character is valid in a filename,
except for NUL and slash; and every character is valid in a file path,
except for NUL.

However, we expect all kinds of parentheses, brackets and angle
brackets to close around file paths. #include <foo/bar.h>

The @ character, for instance, is used in makefile recipes and Windows
batch files to indicate that a line should not be echoed when it is
executed. The word immediately following the @ is a command, which in
many cases is a file name or path.

I do not know of other instances of @ used as a delimiter next to a file name.

Re: systemd @ in filenames not supported by thing-at-point

[Emanuel Berg]

Yuri Khan wrote:

> As you surely know, on *nix, every character
> is valid in a filename, except for NUL and
> slash; and every character is valid in a file
> path, except for NUL.
>
> However, we expect all kinds of parentheses,
> brackets and angle brackets to close around
> file paths. #include <foo/bar.h>

Either way it will break something whatever
you do.

If I was in charge of the systemd project,
I wouldn't have used "@" or any such unusual
char in a filename, and

    $ find ~ -name \*@\* | wc -l
    0

However

    $ sudo find / -name \*@\* | wc -l
    1164

(far from all of them are systemd related).

As expected tho,

    $ sudo find / -name \*@\* | grep -i emacs | wc -l
    0

:)

> I do not know of other instances of @ used as
> a delimiter next to a file name.

There are @ in shell scripting (e.g. zsh),
shell programming (Perl), Makefiles as you
mention, LaTeX relies heavily on it, Biblatex
has it for every entry, Lisp has it (the ,@
insert of a list), they are obviously in email
addresses and remote access (ssh etc.), and
doesn't Java come with some crappy
documentation system where the @s act much like
comment delimiters? And the functional
languages have it. And others!

However they doesn't seem to occur with
filenames that often (but sometimes), which
makes it tempting to include it in the list for
quick access to the 1164 or whatever
files above.

Granted, many of those are typically not files
that you edit but rather bunches of data.

One thing to be considered is that systemd is
now all over the Unix world despite some big
money splinter efforts.

Like everyone else, I don't know anything about
it, and I don't like it, but I do use it :)

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 64 Blogomatic articles -