regexp link on windows problem

regexp link on windows problem

[Rafal Florek]

Hello,

While writing custom function to set regexp search string for c/c++ code I 
stumbled upon a backslash to slash translation problem.
The `org-insert-link' function destroys my regexp by changing all 
backslashes to slashes. 
(I construct the regexp like this: (concat token1 "[ \\t]*" token2))
It happens only under windows, under linux it is ok.
The culprit is the `expand-file-name' function, eg.

for a C source line - a_struct.a_field = 1;

on linux:
(expand-file-name "~/file.h::/a_struct[ \\t]*\\.[ \\t]*a_field[ \\t]*=[ 
\\t]*1[ \\t]*;/"))
becomes:
/home/user/file.h::/a_struct[ \t]*\.[ \t]*a_field[ \t]*=[ \t]*1[ \t]*;/

on windows:
d:/Profiles/user/Application Data/file.h::/a_struct[ /t]*/.[ /t]*a_field[ 
/t]*=[ /t]*1[ /t]*;/

Is this an expected behavior or a bug? Can you recommend a solution or a 
workaround?

regards,
Rafal

Re: regexp link on windows problem

[Bastien]

Hi Rafal,

"Rafal Florek" <raf@irmak.com.pl> writes:

> The `org-insert-link' function destroys my regexp by changing all 
> backslashes to slashes. 

Can you give an example?

> (I construct the regexp like this: (concat token1 "[ \\t]*" token2))
> It happens only under windows, under linux it is ok.
> The culprit is the `expand-file-name' function, eg.
>
> for a C source line - a_struct.a_field = 1;
>
> on linux:
> (expand-file-name "~/file.h::/a_struct[ \\t]*\\.[ \\t]*a_field[ \\t]*=[ 
> \\t]*1[ \\t]*;/"))
> becomes:
> /home/user/file.h::/a_struct[ \t]*\.[ \t]*a_field[ \t]*=[ \t]*1[ \t]*;/
>
> on windows:
> d:/Profiles/user/Application Data/file.h::/a_struct[ /t]*/.[ /t]*a_field[ 
> /t]*=[ /t]*1[ /t]*;/

AFAIK expand-file-name doesn't take a regexp as its argument.

HTH,

-- 
 Bastien

Re: regexp link on windows problem

[Rafal]

Bastien <bzg <at> altern.org> writes:

Hi Bastien,

> 
> Can you give an example?
> 

So I'm trying to write a custom function to set regexp search string for c/c++
code by writing org-create-file-search-functions hook. (code #1 below )

After using the hook by issuing org-store-link in c/c++ buffer, and
org-insert-link in org-mode buffer I noticed that the link has slashes instead
of backslashes in my regexp.
So I delved into the org-insert-link code and found out that it calls
expand-file-name on the whole link (filename::regexp) which translates my
regexp's backslashes to slashes. It happens only on emacs on windows, 
under linux it is ok.
I also experimented by changing the culprit lines of org-store-link and 
it helped (code #2 below) but it seems to be too destructive. 
So I'm wondering if it is a bug that may be fixed or my way of doing 
it is wrong?

regards,
Rafal

GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08 on G41R2F1 
Org-mode version 7.4


;; code #1
(defun make-token-regexp-1()
  (let ((WS "") curpos-tmp)
    (setq curpos (point))
    (beginning-of-line)
    (setq curpos-tmp (point))
    (c-end-of-statement 1 nil t)
    (or (eq curline (line-number-at-pos)) (goto-char curpos))
    (setq curpos (point))
    (c-beginning-of-statement 1 nil t)
    (while (and (eq curline (line-number-at-pos)) (not (eq curpos (point))))
      (setq curpos (point))
      (setq curpos-tmp (point))
      (c-beginning-of-statement 1 nil t))
    (or (eq curline (line-number-at-pos)) (goto-char curpos-tmp))    
    (setq curpos (point))
    (c-forward-token-2)
    (while (and (eq curline (line-number-at-pos)) (not (eq curpos (point))))
      (setq linkv (concat linkv WS (regexp-quote (org-trim (buffer-substring
curpos (point))))))
      (setq curpos (point))
      (and (< 0 (length linkv)) (setq WS "[ \\t]*"))
      (c-forward-token-2)))
  (goto-char curpos)
  (end-of-line)
  (and linkv (setq linkv (concat linkv "[ \\t]*" (regexp-quote (org-trim
(buffer-substring curpos (point)))))))
  linkv)


(defun make-token-regexp()
(interactive)
(c-save-buffer-state ((savepos (point)) linkv tokens curpos (curline
(line-number-at-pos)))
  (make-token-regexp-1)
  (goto-char savepos)    
  (setq description "code-1")
  (and linkv (setq linkv (concat "/" linkv "/")))
  linkv
))

    
(add-hook 'org-create-file-search-functions 'make-token-regexp)


;; code #2
;; original piece of code
		;; We are linking a file with relative path name.
		(setq path (substring (expand-file-name path)
				      (match-end 0)))
	      (setq path (abbreviate-file-name (expand-file-name path)))))))

;;my changes
		;; We are linking a file with relative path name.
		(setq path (substring (expand-file-name path)
				      (match-end 0)))
              (let ((path-1) (search-1))
                (if (string-match "::\\(.+\\)\\'" path)
                    (progn (setq search-1 (match-string 1 path)
                                 path-1 (substring path 0 (match-beginning 0))
                                 path (concat (abbreviate-file-name
(expand-file-name path-1)) "::" search-1))))
                (setq path (abbreviate-file-name (expand-file-name path)))))))

Re: regexp link on windows problem

[David Maus]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

At Fri, 11 Mar 2011 13:41:45 +0000 (UTC),
Rafal wrote:
>
> Bastien <bzg <at> altern.org> writes:
>
> Hi Bastien,
>
> >
> > Can you give an example?
> >
>
> So I'm trying to write a custom function to set regexp search string for c/c++
> code by writing org-create-file-search-functions hook. (code #1 below )
>
> After using the hook by issuing org-store-link in c/c++ buffer, and
> org-insert-link in org-mode buffer I noticed that the link has slashes instead
> of backslashes in my regexp.
> So I delved into the org-insert-link code and found out that it calls
> expand-file-name on the whole link (filename::regexp) which translates my
> regexp's backslashes to slashes. It happens only on emacs on windows,
> under linux it is ok.
> I also experimented by changing the culprit lines of org-store-link and
> it helped (code #2 below) but it seems to be too destructive.
> So I'm wondering if it is a bug that may be fixed or my way of doing
> it is wrong?

I suppose more a glitch.  AFAIK there is currently no distinction
between real link target paths (files, directories etc.) and
expressions that would qualify as a query part of a link (e.g. like
the regexp).

Maybe fiddling with percent escaping (Cf. org-link-escape and
org-link-unescape) might provide a way to protect the slashes from
conversion.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

Re: regexp link on windows problem

[Rafal]

David Maus <dmaus <at> ictsoc.de> writes:

> 
> 
> I suppose more a glitch.  AFAIK there is currently no distinction
> between real link target paths (files, directories etc.) and
> expressions that would qualify as a query part of a link (e.g. like
> the regexp).
> 
> Maybe fiddling with percent escaping (Cf. org-link-escape and
> org-link-unescape) might provide a way to protect the slashes from
> conversion.
> 

I tested it but unfortunately it didn't help. 
What's worse I noticed that my regexp is broken on linux too - all double
slashes '//' (c++ single one line comment) become one slash '/'.


regards,
Rafal