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 -                   

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]

Please don't cross-post to emacs-devel and help-gnu-emacs.
Pick one.  (In this case, the latter might be better.)

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

[Emanuel Berg]

Drew Adams wrote:

> Please don't cross-post to emacs-devel and
> help-gnu-emacs. Pick one. (In this case, the
> latter might be better.)

Phew! Because when you said "pick one", for
a moment I thought *I* was supposed to make
the pick!

And why isn't this a devel issue?

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

    ;; Maintainer: emacs-devel@gnu.org

with `thing-at-point' and 'filename not
getting, 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]

> > Please don't cross-post to emacs-devel and
> > help-gnu-emacs. Pick one. (In this case, the
> > latter might be better.)
> 
> Phew! Because when you said "pick one", for
> a moment I thought *I* was supposed to make
> the pick!

You are.  You judge which list you think is more
appropriate - for you and for others.  Which list would
help you more?  Which would help other users or Emacs
developers more?

> And why isn't this a devel issue?

Maybe it is.  If you think it is, then post to emacs-devel.
From my understanding of your question, I thought (think)
it is better suited for help-gnu-emacs.  But it is up to you
which you choose.  My only request was not to cross-post the
question.

Is it a how-do-I-do-this question or a question about Emacs
development?

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

[Emanuel Berg]

Drew Adams wrote:

> Is it a how-do-I-do-this question or
> a question about Emacs development?

Is it life in general, or computers, that
are binary?

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

> > Is it a how-do-I-do-this question or
> > a question about Emacs development?
> 
> Is it life in general, or computers, that are binary?

If you are not strictly just-black-or-white-with-no-gray you
will understand that summary question, especially following
the more detailed explanation, as really asking:

 "Is it MORE a how-do-I-do-this question or MORE a question
  about Emacs development?"

It's a judgment call, and yes, it's your call - you choose.
You might sometimes have difficulty deciding - things are
not always only black-or-white, but please make a choice,
as opposed to cross-posting.

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

[Emanuel Berg]

Drew Adams wrote:

> If you are not strictly
> just-black-or-white-with-no-gray you will
> understand that summary question, especially
> following the more detailed explanation, as
> really asking:
>
> "Is it MORE a how-do-I-do-this question or
> MORE a question about Emacs development?"
>
> It's a judgment call, and yes, it's your call
> - you choose. You might sometimes have
> difficulty deciding - things are not always
> only black-or-white, but please make
> a choice, as opposed to cross-posting.

Yes:

    https://www.youtube.com/watch?v=UrDV6VksSRU

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 426 bytes --]

On 2016-07-30 11:33, Emanuel Berg wrote:
> https://www.youtube.com/watch?v=UrDV6VksSRU

I have no idea what this is about, or what it has to do with Emacs. In any case, the original issue sounds like a bug to me, and you seem to have a reasonable-looking fix for it. Can you prepare a patch and send it with M-x report-emacs-bug? That would be very useful; we could probably discuss that fix there.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Emanuel Berg]

Clément Pit--Claudel wrote:

> I have no idea what this is about, or what it
> has to do with Emacs. In any case, the
> original issue sounds like a bug to me, and
> you seem to have a reasonable-looking fix for
> it. Can you prepare a patch and send it with
> M-x report-emacs-bug? That would be very
> useful; we could probably discuss that
> fix there.

By "preparing a patch", do you mean there is
some formal way of doing that? If so, I am not
familiar with that. (I know of
`report-emacs-bug', of course.)

But the patch would amount to adding an @ to

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

which is at line 242,
/usr/share/emacs/24.4/lisp/thingatpt.el.gz

However, in my initial post I added the @
*first* which I have since learned on
gnu.emacs.help turns the original, initial dash
into an interval (when it doesn't appear first
anymore), i.e., all of [@, ~] in math notation
are included which wasn't the intention,
for sure!

So better put the @ after the initial dash so
the dash will stay a char an nothing else, with
@ and only @ included 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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]

On 2016-07-30 20:23, Emanuel Berg wrote:
> Clément Pit--Claudel wrote:
> 
>> I have no idea what this is about, or what it
>> has to do with Emacs. In any case, the
>> original issue sounds like a bug to me, and
>> you seem to have a reasonable-looking fix for
>> it. Can you prepare a patch and send it with
>> M-x report-emacs-bug? That would be very
>> useful; we could probably discuss that
>> fix there.
> 
> By "preparing a patch", do you mean there is
> some formal way of doing that? If so, I am not
> familiar with that. (I know of
> `report-emacs-bug', of course.)

:) It's very easy. You checkout the Emacs source tree with git, then make your change, commit it with a message in Changelog format), test it, and finally use `git-format-patch HEAD~1` to save it as a .patch file. Then you can post it as an attachment to a report-emacs-bug email summarizing the issue and the proposed fix.

As a small bonus, this process ensures that you're credited for finding and fixing the issue in the Emacs history, which is nice :); also, it makes it easy for people to test the proposed fix (although, arguably, it's already easy in this case).

In general, you need to sign a contributor agreement to send patches to Emacs; this particular fix however counts as a "trivial" fix, and thus is exempted from this. But if you haven't yet done so, signing the CLA is very easy, and will make it smoother to contribute more significant patches in the future :)

> However, in my initial post I added the @
> *first* which I have since learned on
> gnu.emacs.help turns the original, initial dash
> into an interval (when it doesn't appear first
> anymore), i.e., all of [@, ~] in math notation
> are included which wasn't the intention,
> for sure!

That's right; nice catch. I'd suggest sending the patch to bug-gnu-emacs, and seeing if people have other similar insight.

Cheers and thanks for catching this issue and proposing a fix!
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]