[Orgmode] Re: Org-protocol / Chrome on Linux
Mattias Jämting writes:
> Hello again,
>
> For reference, this is how i finally got org-protocol to work in
> chrome on ubuntu 10.10:
>
> The problem was that chrome was running xdg-open for handling external
> protocols. xdg-open, or it's companion gvfs-open, couldn't parse the
> rather complex URL which the org-capture bookmarklet generated.
I found a minimal test case and filed a bug for this:
https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/688436
The key to this is that using "%2F" in the URL *path* causes gvfs-open
and gnome-open to raise an error.
$ gvfs-open "http://foo.com/bar%2Fqux";
gvfs-open: http://foo.com/bar%2Fqux: error opening location: Operation not
supported
While this is a bug in those packages, I've always thought the
org-protocol URL format was problematic. Why not use URL query args
instead? Note that gvfs-open and gnome-open handle that just fine:
$ gvfs-open "http://foo.com?blah=bar%2Fqux";
It seems like org-protocol would have fewer edge case problems and would
have URLs that would make more sense to more people if we used URL query
args instead:
org-protocol://store-link?URL=http%3A%2F%2Ffoo.com&TITLE=Bar%20Qux&BODY=blah%20blah
If this sounds good, I'd be happy to submit patches for this. Provided
there's something available in emacs for parsing URL query args.
Ross
> So i realized that xdg-open is just a shell-script so then i modified
> the function open-gnome() in it like this:
>
> open_gnome()
> {
> # Handle org-protocol
> if (echo "$1" | grep -q '^org-protocol://'); then
> emacsclient "$1"
> else
> # This is the standard way...
> if gvfs-open --help 2>/dev/null 1>&2; then
> gvfs-open "$1"
> else
> gnome-open "$1"
> fi
> fi
> ...
> }
>
> Suddenly all works. Remember to back-up xdg-open if you want to try this.
>
> Mattias
>
> 2010/9/30 Sebastian Rose :
>> Sebastian Rose writes:
>>> Mattias Jämting writes:
Yes i'm running a pretty standard Ubuntu 10.04 setup.
I managed to get it working on chrome by removing the
encodeURIComponent command on location.href.
I could simulate it in the terminal like this.
matt...@helium:~$ xdg-open
org-protocol://capture://http%3A%2F%2Forgmode.org
Error showing URL: Operation not supported
matt...@helium:~$ xdg-open org-protocol://capture://http://orgmode.org>>>
matt...@helium:~$ (worked)
Strange that it worked in FF. Maybe Chrome and FF encodes URIs differently?
>>>
>>>
>>> Ooops!
>>>
>>> I just was going to blame Google.
>>>
>>> Looking into the ECMA standard, I found this:
>>>
>>> 15.1.3 URI Handling Function Properties
>>>
>>> ... ...
>>>
>>> A URI is composed of a sequence of components separated by
>>> component separators. The general form
>>> is:
>>> Scheme : First / Second ; Third ? Fourth
>>>
>>> where the italicised names represent components and the “:”, “/”,
>>> “;” and “?” are reserved characters used as separators. The
>>> encodeURI and decodeURI functions are intended to work with
>>> complete URIs; they assume that any reserved characters in the
>>> URI are intended to have special meaning and so are not
>>> encoded. The encodeURIComponent and decodeURIComponent functions
>>> are intended to work with the individual component parts of a
>>> URI; they assume that any reserved characters represent text and
>>> so must be encoded so that they are not interpreted as reserved
>>> characters when the component is part of a complete URI.
>>>
>>>
>>> That document states "encodeURI" is to be used with complete URIs (as
>>> the name says...). Funny. Chrome is the only browser that works like
>>> that :)
>>>
>>> I'll go and adjust the docs.
>>>
>>>
>>> Thanks for your Report!!
>>>
>>
>>
>>
>> Actually --- errr --- there is nothing to adjust. The docs are exactly
>> right.
>>
>> This is because of some örfflkjsgs in xdg-open.
>>
>> No one ever said something about xdg-open. Org-protocol is supposed to
>> work with emacsclient:
>>
>> matt...@helium:~$ emacsclient
>> org-protocol://capture://http%3A%2F%2Forgmode.org
>>
>>
>> works.
>>
>>
>> Sebastian
>>
>>
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol
Richard Riley writes: > Richard Riley writes: > >> I'm trying to get FF working with org again - >> >> http://orgmode.org/worg/org-contrib/org-protocol.php >> >> It says >> >> , >> |1. Type "about:config" into the location bar and press enter. >> |2. Click "I'll be careful, I promise!" to continue. >> |3. Right-click on the grid >> |4. Choose "New" -> "String" from the context menu. >> |5. Enter "network.protocol-handler.app.org-protocol" as the properties >> name. >> |6. Click "OK". >> |7. Leave the value blank. >> |8. Next time you try to open a location "org-protocol://..." FF will >> ask you for the program to use. Enter the path to emacsclient. >> ` >> >> It doesnt prompt me for a program. Is this uptodate or is there a better >> step by step guide? >> > > Despite having 3.5, the instructions for getting the app registered > didnt work for some reason (iceweasel?). Anyway, the gconftool method > worked. You can use firefox-protocol.el from http://mercurial.intuxication.org/hg/emacs-bookmark-extension/ M-x firefox-protocol-installer-install Don't know if it work with iceweasel, but i have set many protocols here in firefox without any failures. You will find a documentation file bookmark-extensions-documentation.rst. -- Thierry Volpiatto Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol
Richard Riley writes: > I'm trying to get FF working with org again - > > http://orgmode.org/worg/org-contrib/org-protocol.php > > It says > > , > |1. Type "about:config" into the location bar and press enter. > |2. Click "I'll be careful, I promise!" to continue. > |3. Right-click on the grid > |4. Choose "New" -> "String" from the context menu. > |5. Enter "network.protocol-handler.app.org-protocol" as the properties > name. > |6. Click "OK". > |7. Leave the value blank. > |8. Next time you try to open a location "org-protocol://..." FF will ask > you for the program to use. Enter the path to emacsclient. > ` > > It doesnt prompt me for a program. Is this uptodate or is there a better > step by step guide? > Despite having 3.5, the instructions for getting the app registered didnt work for some reason (iceweasel?). Anyway, the gconftool method worked. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and web links
Matt Lundin writes:
> Hi Richard,
>
>> e.g I want my new org item first line to be something like the following
>> if I invoke org-remember from conkeror on a web page having first
>> hilited "blah blah" somewhere on the page
>
> With the following org-remember-template:
>
> --8<---cut here---start->8---
> (setq org-remember-templates
> '(
> ;; other templates here
> ("protocol" ?w "* %c\n %U\n\n %i" nil bottom nil)
> ))
> --8<---cut here---end--->8---
>
Heh, typo in my conkerrrc where I had used a different protocol template
selector. All sorted now. Thanks for taking the time to reply.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and web links
Hi Richard,
Richard Riley writes:
> Does anyone have a "w" template which can store a hot link using the
> page title (not just the url) in addition to the selection under the
> title line? The problem I find is that I havent got the combo right to
> do this : if I select something on a conkeror page and then call
> org-remember the selection becomes the %c which is usually used to store
> an encoded title and url org link.
>
> e.g I want my new org item first line to be something like the following
> if I invoke org-remember from conkeror on a web page having first
> hilited "blah blah" somewhere on the page
With the following org-remember-template:
--8<---cut here---start->8---
(setq org-remember-templates
'(
;; other templates here
("protocol" ?w "* %c\n %U\n\n %i" nil bottom nil)
))
--8<---cut here---end--->8---
I get the following when I select text on the org-mode home page in
conkeror and call org-protocol-remember (which I have bound to C-c r in
conkeror):
--8<---cut here---start->8---
* [[http://orgmode.org/][Org-Mode: Your Life in Plain Text]]
[2010-04-06 Tue 16:07]
Org-mode is for keeping notes, maintaining ToDo lists, doing project
planning, and authoring with a fast and effective plain-text system.
--8<---cut here---end--->8---
What do you have in your conkerorrc? I'm currently using the setup I put
up on the org-protocol page on Worg:
http://orgmode.org/worg/org-contrib/org-protocol.php#sec-8.1
Best,
Matt
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol: non-ASCII characters
Jan Böcker writes: > On 12.02.2010 23:23, dmg wrote: > >> For evince, I think I have found a problem in the parsing of the link. >> Evince already encodes >> the URL, but it does not encode the '/', hence you will get a link like this: >> >> emacsclient >> 'org-protocol://remember://docview/tmp/00%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA.pdf::1' >> >> the filename is /tmp/00áéíóú.pdf >> >> But emacs incorrectly stops parsing the link after tmp/ > > I think I have found the proper way to handle this in evince. > Check out the attached patch or pull from: > > git://github.com/jboecker/evince.git > > This code first retrieves the non-URI-encoded UTF-8 filename and passes > that to uri_encode. Should g_file_get_path return NULL, we abort, > because the URI specifies something in gnomes VFS layer that has no > local path, so the link would not work, anyway. > >> By the way, xournal now supports store-link > > Works as advertised, thanks! > > The only problem I have left now is a cosmetic one: when I store a link > to, say, /tmp/test.xoj, in Org it becomes file://tmp/test.xoj instead of > file:/tmp/test.xoj. (I have patched xournal and evince to generate file: > instead of docview: links.) > > This is because org-protocol-sanitize-uri is called after decoding the > string, allegedly because emacsclient compresses multiple slashes in a > row to one. However, it seems that this function should be applied > /before/ the string is URL-decoded. Is this a bug? Hm - yes and no :) I did not want to expose to much of the encoding and decoding problem to the users. It's already complicated enough to add a bookmarklet. `org-protocol-sanitize-uri' just works for the usual bookmarking and remembering stuff we used it for - and everyone used it for `http:' and similar protocols. How about exending `org-protocol-sanitize-uri' to detect certain protocols like `file:' and drop the extra slash for those? Or, better, add an extra slash, which would be the correct way to express an absolute path (though most apps on Linux these days take `file:/one/slash/only'). org-protocol could be used for other purposes, too. Shouldn't Org-mode follow links like [[file:///absolute/path]] and [[file://absolute/path]] as we would expect? (OK, I know, emacsclient should be fixed...) This is, what my browsers here do. They both do not care for the number of slashes. Opera 10 changes a correct URI to it's own special URI (note the `localhost'): file://localhost/home Firefox takes the `correct' URI: file:///home/sebastian Here is a patch, that would fix it. We could add more exceptions to the if-statement as needed. diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 9881e9f..b80131c 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -267,8 +267,11 @@ Here is an example: "emacsclient compresses double and tripple slashes. Slashes are sanitized to double slashes here." (when (string-match "^\\([a-z]+\\):/" uri) -(let* ((splitparts (split-string uri "/+"))) - (setq uri (concat (car splitparts) "//" (mapconcat 'identity (cdr splitparts) "/") +(let* ((splitparts (split-string uri "/+")) + (extraslash "//")) + (if (string= "file:" (car splitparts)) + (setq extraslash "/")) + (setq uri (concat (car splitparts) extraslash (mapconcat 'identity (cdr splitparts) "/") uri) Best wishes, Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol: non-ASCII characters
On 12.02.2010 23:23, dmg wrote:
> For evince, I think I have found a problem in the parsing of the link.
> Evince already encodes
> the URL, but it does not encode the '/', hence you will get a link like this:
>
> emacsclient
> 'org-protocol://remember://docview/tmp/00%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA.pdf::1'
>
> the filename is /tmp/00áéíóú.pdf
>
> But emacs incorrectly stops parsing the link after tmp/
I think I have found the proper way to handle this in evince.
Check out the attached patch or pull from:
git://github.com/jboecker/evince.git
This code first retrieves the non-URI-encoded UTF-8 filename and passes
that to uri_encode. Should g_file_get_path return NULL, we abort,
because the URI specifies something in gnomes VFS layer that has no
local path, so the link would not work, anyway.
> By the way, xournal now supports store-link
Works as advertised, thanks!
The only problem I have left now is a cosmetic one: when I store a link
to, say, /tmp/test.xoj, in Org it becomes file://tmp/test.xoj instead of
file:/tmp/test.xoj. (I have patched xournal and evince to generate file:
instead of docview: links.)
This is because org-protocol-sanitize-uri is called after decoding the
string, allegedly because emacsclient compresses multiple slashes in a
row to one. However, it seems that this function should be applied
/before/ the string is URL-decoded. Is this a bug?
>From f777bca64fd23066f626bc55cee6a81d6e03dac5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20B=C3=B6cker?=
Date: Sat, 13 Feb 2010 12:38:39 +0100
Subject: [PATCH 1/2] bugfix in encode_uri: cast to unsigned char to get the
correct byte value
---
libview/ev-view.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libview/ev-view.c b/libview/ev-view.c
index c334fdc..1130d39 100644
--- a/libview/ev-view.c
+++ b/libview/ev-view.c
@@ -5775,8 +5775,8 @@ static void encode_uri(gchar *encoded_uri, gint bufsize,
const gchar *uri)
if (k + 4 >= bufsize)
break;
encoded_uri[k++] = '%';
- encoded_uri[k++] = hexa[uri[i] / 16];
- encoded_uri[k++] = hexa[uri[i] % 16];
+ encoded_uri[k++] = hexa[(unsigned char)uri[i] / 16];
+ encoded_uri[k++] = hexa[(unsigned char)uri[i] % 16];
}
}
encoded_uri[k] = 0;
--
1.6.6.1
>From 1003e7809fbf2823e23b8dc8c7e3b46dfad0bcd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20B=C3=B6cker?=
Date: Sat, 13 Feb 2010 12:37:31 +0100
Subject: [PATCH 2/2] URI-encode the utf-8 filename instead of a partially
URI-encoded gnome vfs uri
---
libview/ev-view.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/libview/ev-view.c b/libview/ev-view.c
index 1130d39..4fda860 100644
--- a/libview/ev-view.c
+++ b/libview/ev-view.c
@@ -5800,9 +5800,18 @@ ev_view_annotate (EvView *ev_view, gchar *uri, int page)
EvDocumentInfo *p = ev_document_get_info(ev_view->document);
+ // get the real file path from evince
+ GFile *gfile = g_file_new_for_uri(uri);
+ char *filePath = g_file_get_path(gfile);
+ g_object_unref (gfile);
+ if (!filePath) {
+ printf("invalid file path");
+ return;
+ }
+
tempSel = g_malloc(ANN_MAX_BUFFER_LEN);
tempFileName = g_malloc(strlen(uri) * 4);
-
+
if (!EV_IS_SELECTION (ev_view->document)) {
strcmp(tempSel, "");
text = "";
@@ -5811,20 +5820,13 @@ ev_view_annotate (EvView *ev_view, gchar *uri, int page)
text = get_selected_text (ev_view);
encode_uri(tempSel, ANN_MAX_BUFFER_LEN, text);
}
- /// encode filename
-#define ANN_FILE_PREFIX "file://"
- if (strncmp(uri,ANN_FILE_PREFIX, strlen(ANN_FILE_PREFIX) ) == 0) {
- // skip the prefix
- encode_uri(tempFileName,
- ANN_MAX_BUFFER_LEN, uri+strlen(ANN_FILE_PREFIX));
- } else {
- encode_uri(tempFileName, ANN_MAX_BUFFER_LEN, uri);
- }
-
+
+ encode_uri(tempFileName, ANN_MAX_BUFFER_LEN, filePath);
+
tempCommandLine = g_malloc(strlen(tempSel) + strlen(tempFileName) +
200);
- printf("remember%s%s%s%d\n", p->title, uri, text, page);
sprintf(tempCommandLine, "emacsclient
'org-protocol://remember://docview:%s::%d'", tempFileName, page+1);
+ printf("remember%s%s%s%d\n", p->title, filePath, text,
page);
printf("temp: [%s]\n", tempCommandLine);
if (!g_spawn_command_line_async (tempCommandLine, &error)) {
@@ -5836,6 +5838,8 @@ ev_view_annotate (EvView *ev_view, gchar *uri, int page)
g_free (tempSel);
g_free (tempCommandLine);
g_free (tempFileName);
+ g_free (filePath);
+
#ifdef fork
--
1.6.6.1
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu
Re: [Orgmode] Re: org-protocol: non-ASCII characters
> Basically, it is OK to url-encode each character who's binary
> representation start with 1 (i.e., the value of the character is higher
> than 127). The text to be url-encoded should be UTF-8 ideally.
>
> If you use glib::ustring, it's easy to transform any iso-8859 string to
> utf-8. Each character, whos binary representation start with a 1, has to
> be url-encoded as well as the `%' character [1], but you could as
> url-encode the entire utf-8 string.
>
>
Ok, I think I understand the problem now. I have updated xournal to encode the
filename from its encoding to uft8. that seems to work. See
http://github.com/dmgerman/xournal
For evince, I think I have found a problem in the parsing of the link.
Evince already encodes
the URL, but it does not encode the '/', hence you will get a link like this:
emacsclient
'org-protocol://remember://docview/tmp/00%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA.pdf::1'
the filename is /tmp/00áéíóú.pdf
But emacs incorrectly stops parsing the link after tmp/
By the way, xournal now supports store-link
--dmg
>
>
>
>
> The function that does the decoding is `org-protocol-unhex-string' which
> in turn uses `org-protocol-unhex-compound'.
>
>
> `man utf-8` shows, how org-protocol tries to decode characters.
>
>
> The JavaScript-Funktion `encodeURIComponent()' returns exactly what we
> need. It recodes a string to utf-8 and then encodes all characters,
> except digits, ASCII letters and these punctuation characters: -_.!~*'()
>
> See ECMA-262 Standard, Section 15.1.3
> (http://bclary.com/2004/11/07/ecma-262.html#a-15.1.3 [2]):
>
> "The character is first transformed into a sequence of octets using
> the UTF-8 transformation..."
>
>
> Again, note, that the decoding mechanism relies on the fact, that the
> sequence to decode is url-encoded UTF-8.
>
>
>
>
>
> Example:
>
> The url-encoded unicode representation of the German umlaut `ö' is
> `%C3%B6'. Thus
>
> (org-protocol-unhex-string "%C3%B6")
>
> gives you "ö".
>
> In iso-8859-1, the url-encoded representation of the same character `ö' was
> `%F6'. But
>
> (org-protocol-unhex-string "%F6")
>
> gives you "" - the empty string. There is no utf-8 character with this binary
> representation, since every byte starting with a 1 (i.e. is bigger than 127)
> starts a multibyte sequence (2 or more bytes).
>
> But:
>
> (org-protocol-unhex-string "%2F%3C")
>
> gives you, as expected, "/<" which shows, that you could savely
> url-encode each and every character of a utf-8 encoded string.
>
>
> == Footnotes:
>
> [1] The percent character `%' has to be encoded, if followed by
> [0-9A-Fa-f]{2}, because org-protocol will assume, that a sequence
> matching "\\(%[0-9a-f][0-9a-f]\\)+" is an encoded character. That
> said, a `%' has to be url-encoded, since one will hardly ever
> know for sure, that a `%' is never followed by "[0-9a-f][0-9a-f]".
>
> [2] Get a PDF version of ECMA-262 third edition here:
> http://www.ecma-international.org/publications/standards/Ecma-262.htm
>
>
--
--dmg
---
Daniel M. German
http://turingmachine.org
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol: non-ASCII characters
Jan Böcker writes:
> On 06.02.2010 14:50, Jan Böcker wrote:
>> AFAIK, your current approach is correct.
>
> I was wrong. The attached patch fixes a bug in the encode_uri function.
> That fixes the non-ASCII characters problem in xournal for me.
>
> The gchar type is just typedef'd to char, which means it is signed. To
> get the byte value, it must be cast to unsigned int first.
>
> - Jan
Hi Jan and Daniel!
Sorry for answering with that long delay. I read Daniel's mail last
week, but I had to think about the answer.
I'll just describe, what the `org-protocol-unhex-string' functions do
here, and what they expect as arguments.
Basically, it is OK to url-encode each character who's binary
representation start with 1 (i.e., the value of the character is higher
than 127). The text to be url-encoded should be UTF-8 ideally.
If you use glib::ustring, it's easy to transform any iso-8859 string to
utf-8. Each character, whos binary representation start with a 1, has to
be url-encoded as well as the `%' character [1], but you could as
url-encode the entire utf-8 string.
The function that does the decoding is `org-protocol-unhex-string' which
in turn uses `org-protocol-unhex-compound'.
`man utf-8` shows, how org-protocol tries to decode characters.
The JavaScript-Funktion `encodeURIComponent()' returns exactly what we
need. It recodes a string to utf-8 and then encodes all characters,
except digits, ASCII letters and these punctuation characters: -_.!~*'()
See ECMA-262 Standard, Section 15.1.3
(http://bclary.com/2004/11/07/ecma-262.html#a-15.1.3 [2]):
"The character is first transformed into a sequence of octets using
the UTF-8 transformation..."
Again, note, that the decoding mechanism relies on the fact, that the
sequence to decode is url-encoded UTF-8.
Example:
The url-encoded unicode representation of the German umlaut `ö' is
`%C3%B6'. Thus
(org-protocol-unhex-string "%C3%B6")
gives you "ö".
In iso-8859-1, the url-encoded representation of the same character `ö' was
`%F6'. But
(org-protocol-unhex-string "%F6")
gives you "" - the empty string. There is no utf-8 character with this binary
representation, since every byte starting with a 1 (i.e. is bigger than 127)
starts a multibyte sequence (2 or more bytes).
But:
(org-protocol-unhex-string "%2F%3C")
gives you, as expected, "/<" which shows, that you could savely
url-encode each and every character of a utf-8 encoded string.
== Footnotes:
[1] The percent character `%' has to be encoded, if followed by
[0-9A-Fa-f]{2}, because org-protocol will assume, that a sequence
matching "\\(%[0-9a-f][0-9a-f]\\)+" is an encoded character. That
said, a `%' has to be url-encoded, since one will hardly ever
know for sure, that a `%' is never followed by "[0-9a-f][0-9a-f]".
[2] Get a PDF version of ECMA-262 third edition here:
http://www.ecma-international.org/publications/standards/Ecma-262.htm
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol: non-ASCII characters
On 06.02.2010 14:50, Jan Böcker wrote: > AFAIK, your current approach is correct. I was wrong. The attached patch fixes a bug in the encode_uri function. That fixes the non-ASCII characters problem in xournal for me. The gchar type is just typedef'd to char, which means it is signed. To get the byte value, it must be cast to unsigned int first. - Jan diff --git a/src/xo-misc.c b/src/xo-misc.c index 6f0528c..c2582c7 100644 --- a/src/xo-misc.c +++ b/src/xo-misc.c @@ -2441,8 +2441,8 @@ void encode_uri(gchar *encoded_uri, gint bufsize, const gchar *uri) if (k + 4 >= bufsize) break; encoded_uri[k++] = '%'; - encoded_uri[k++] = hexa[uri[i] / 16]; - encoded_uri[k++] = hexa[uri[i] % 16]; + encoded_uri[k++] = hexa[(unsigned char)uri[i] / 16]; + encoded_uri[k++] = hexa[(unsigned char)uri[i] % 16]; } } encoded_uri[k] = 0; ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol: non-ASCII characters
> I have been looking around and I am not sure how to solve this
> problem. Withing Evince and Xournal I am encoding any non alphanum (as
> defined by the C macro) each byte that is contained in the filename
> individually.
>
> Does anybody know which are the characters above 0 (zero) that need to
> be encoded for a safe org link?
AFAIK, your current approach is correct.
I think I figured it out for evince: the file name you get from evince
is already URI-encoded.
The attached patch fixes the problem for me, but I do not know if it is
the right thing to do. I assume that the forward slashes in the file
name still have to be encoded so that org-protocol is not confused; the
patch disables URI-encoding for percent signs, so that already
URI-encoded characters pass through unharmed.
- Jan
diff --git a/libview/ev-view.c b/libview/ev-view.c
index c8145ff..c575831 100644
--- a/libview/ev-view.c
+++ b/libview/ev-view.c
@@ -5752,7 +5752,7 @@ ev_view_previous_page (EvView *view)
static gint is_unchanged_uri_char(char c)
{
- return isalnum(c);
+ return ((c == '%') || isalnum(c));
}
static void encode_uri(gchar *encoded_uri, gint bufsize, const gchar *uri)
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol bug
Andreas Burtzlaff writes: > On Wed, 11 Nov 2009 10:06:36 +0100 > Sebastian Rose wrote: >> >> Andreas, could you check if it works for you, too? >> > > Yes, it works with both 23 and 22. > > Thanks for your effort. Tanks for checking Andreas, Sebastian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol bug
On Wed, 11 Nov 2009 10:06:36 +0100 Sebastian Rose wrote: > > Andreas, could you check if it works for you, too? > Yes, it works with both 23 and 22. Thanks for your effort. Andreas ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol bug
Hi Carsten and Andreas, thanks to Kenichi Handa, here is a proposal to fix the issus mentioned below. I tested it in emacs 22 and 23 and it seems to work just fine. Carsten, as always if I use some new elisp construct, please review the patch. I used `eval-when-compile' and `defsubst' to inline the char-to-string function, since it might be called very often, depending on the amount of text passed to emacs through org-protocol. Andreas, could you check if it works for you, too? diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 133fae4..9b34ed9 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -280,6 +280,19 @@ decode each split part." (mapcar 'org-protocol-unhex-string split-parts)) split-parts))) + +;; This inline function is needed in org-protocol-unhex-compound to do +;; the right thing to decode UTF-8 char integer values. +(eval-when-compile + (if (>= emacs-major-version 23) + (defsubst org-protocol-char-to-string(c) + "Defsubst to decode UTF-8 character values in emacs 23 and beyond." + (char-to-string sum)) +(defun org-protocol-char-to-string (c) + "Defsubst to decode UTF-8 character values in emacs 22." + (string (decode-char 'ucs sum) + + (defun org-protocol-unhex-string(str) "Unhex hexified unicode strings as returned from the JavaScript function encodeURIComponent. E.g. `%C3%B6' is the german Umlaut `ü'." @@ -331,7 +344,7 @@ encodeURIComponent. E.g. `%C3%B6' is the german Umlaut `ü'." (setq sum (+ (lsh sum shift) val)) (if (> eat 0) (setq eat (- eat 1))) (when (= 0 eat) - (setq ret (concat ret (char-to-string sum))) + (setq ret (concat ret (org-protocol-char-to-string sum))) (setq sum 0)) )) ;; end (while bytes ret )) > Andreas Burtzlaff writes: >> Hello Sebastian, >> >> I'm not sure you noticed the org-protocol bug in this thread on the >> org-mode list: >> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg18673.html >> >> To sum it up, when the title of a page contains an &ndash then the error >> org-protocol-unhex-compound: Invalid character: 8211, #o20023, #x2013 >> occurs when invoking remember in Emacs 22, not in Emacs 23. >> >> Just wondering whether you have any idea how this could be fixed. Sebastian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol bug
Hi Andreas, seems this has to do with the internal encoding of Emacs. I need some advice at this point from the emacs-devel list. I'll be back if I find out something. Andreas Burtzlaff writes: > Hello Sebastian, > > I'm not sure you noticed the org-protocol bug in this thread on the > org-mode list: > http://www.mail-archive.com/emacs-orgmode@gnu.org/msg18673.html > > To sum it up, when the title of a page contains an &ndash then the error > org-protocol-unhex-compound: Invalid character: 8211, #o20023, #x2013 > occurs when invoking remember in Emacs 22, not in Emacs 23. > > Just wondering whether you have any idea how this could be fixed. Sebastian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and safari
Matthew Lundin writes:
[...]
>> As for FF, the instructions should work. See also:
>>
>>http://kb.mozillazine.org/Register_protocol#Linux_and_Mac
>
> These instructions are incorrect. I can confirm that setting a protocol
> does not work in Firefox on Mac OS - there is a bug that's been around
> for a long time that prevents associating protocols with an application
> and/or path. See this mailing list post:
For Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20091010
Iceweasel/3.5.3 (Debian-3.5.3-2) these steps does the trick for me:
- Add these two preferences to prefs.js:
--8<---cut here---start->8---
user_pref("network.protocol-handler.app.org-protocol", "/usr/bin/emacsclient -t
%L");
user_pref("network.protocol-handler.external.org-protocol", true);
--8<---cut here---end--->8---
- Start emacs as daemon.
- Start FF from the command line. It wouldn't work if started using a
shortcut (i.e. with Gnome main menu entry). IIRC I tried to get a
result without any success until I started FF from the X terminal by
accident.
- Org-mode must be activated. I suspect that my configuration broken in
a some way that prevents org-mode + org-remeber functionality to be
available just right after emacs was started. But I usually activate
agenda view very early so this is not a problem for me.
--
MAN-UANIC
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and safari
Matthew Lundin writes: > Sebastian Rose writes: > >> Greg Newman writes: > >>> I did try to get it working with Firefox 3.x and it's not working. >>> I followed the worg instructions ( >>> http://orgmode.org/worg/org-contrib/org-protocol.php ) for FF and tried the >>> verification links with no luck. >>> Firefox just screams at me "Firefox doesn't know how to open this address, >>> because the protocol (org-protocol) isn't associated with any program." >>> 2. Any clue why this isn't working? >> >> >> As for FF, the instructions should work. See also: >> >>http://kb.mozillazine.org/Register_protocol#Linux_and_Mac > > These instructions are incorrect. I can confirm that setting a protocol > does not work in Firefox on Mac OS - there is a bug that's been around > for a long time that prevents associating protocols with an application > and/or path. See this mailing list post: > > http://article.gmane.org/gmane.emacs.orgmode/12883 > > And this bug report: > > https://bugzilla.mozilla.org/show_bug.cgi?id=471724 Not sure if those informations are the end of all that... On Windows, as on MAC (I think), protocols are not registered in FF itself too. I think what we need is a MAC freak, who provides the apple script (or what ever is used on MAC for such things), that installs the protocol handler on that system (for FF, Safari, IE Mac version, Acrobat etc.). Maybe this helps?? http://www.xmldatabases.org/WK/blog/1154_Handling_URL_schemes_in_Cocoa.item That app would just have to call emacsclient.. > My solution for this bug was to install Arch Linux on my Macbook. ;) Haha - Not everyone will want to do that I think :) Sebastian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and safari
Sebastian Rose writes: > Greg Newman writes: >> I did try to get it working with Firefox 3.x and it's not working. >> I followed the worg instructions ( >> http://orgmode.org/worg/org-contrib/org-protocol.php ) for FF and tried the >> verification links with no luck. >> Firefox just screams at me "Firefox doesn't know how to open this address, >> because the protocol (org-protocol) isn't associated with any program." >> 2. Any clue why this isn't working? > > > As for FF, the instructions should work. See also: > >http://kb.mozillazine.org/Register_protocol#Linux_and_Mac These instructions are incorrect. I can confirm that setting a protocol does not work in Firefox on Mac OS - there is a bug that's been around for a long time that prevents associating protocols with an application and/or path. See this mailing list post: http://article.gmane.org/gmane.emacs.orgmode/12883 And this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=471724 My solution for this bug was to install Arch Linux on my Macbook. ;) - Matt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Org protocol and new frame for remember
Sebastian Rose writes: > Matthew Lundin writes: >> But I thought it might be a nice addition to org-protocol if there were >> a variable that accomplishes this (e.g., >> org-protocol-remember-in-new-frame). I'd be eager to know if I am >> missing a current way to do this. > > Such a variable does not exist. org-protocol does nothing especially > related to org-remember. org-protocol://remember:/ is just one of the > pre-defined statndard handlers. > > But you could as well define your own handler that behaves > differently. Maybe just copying `org-protocol-remember' from > lisp/org-protocol.el as a starting point. > > Reading > http://orgmode.org/worg/org-tutorials/org-protocol-custom-handler.php > should help (if it doesn't, please let us know what's missing). Thanks for the tip. I had given cursory glance to the custom handler page, but now have incentive for closer study. Best, Matt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Org protocol and new frame for remember
Matthew Lundin writes: > My apologies for the initial post fragment. (Note to self: C-c C-c > binding for jumping to footnote reference does not work in Gnus!) > > Let's try this again: > > Hi all, > > I've recently begun to use org-protocol. I've been using it with the > intriguing emacs-inspired browser Conkeror.[1] With the help of a nice > blog post by Tassilo,[2] I have worked out a basic way to send snippets > from the browser to remember via org-protocol. The great thing about > Conkeror is that you can invoke org-remember the same way you do in > emacs (either with M-x org-remember or, via a custom keybinding, with > C-c r). > > I've posted my hacks at the bottom of the org-protocol page on Worg. Any > advice/feedback would be greatly appreciated: > > http://orgmode.org/worg/org-contrib/org-protocol.php#conkeror-setup > > (My apologies to Sebastian if these should go somewhere else -- feel > free to move them!) Thanks for adding this! Maybe we'll split the page one day because of it's shear size and add links to certain setups. But for now I'm glad to see people adding stuff like that :) > As I experiment with the fabulous org-protocol, I wonder whether I've > missed a variable in org-protocol that tells the function > org-protocol-remember to create a *temporary* new frame (i.e., one that > pops up above the browser and then disappears after typing C-c C-c). > > I know I can set the variable remember-in-new-frame to t, but I would > ideally like the new frame only for org-protocol-remember and not for > other invocations of remember. My current solution is to advise the > function org-protocol-remember (i.e., to set remember-in-new-frame > locally for that function). > > But I thought it might be a nice addition to org-protocol if there were > a variable that accomplishes this (e.g., > org-protocol-remember-in-new-frame). I'd be eager to know if I am > missing a current way to do this. Such a variable does not exist. org-protocol does nothing especially related to org-remember. org-protocol://remember:/ is just one of the pre-defined statndard handlers. But you could as well define your own handler that behaves differently. Maybe just copying `org-protocol-remember' from lisp/org-protocol.el as a starting point. Reading http://orgmode.org/worg/org-tutorials/org-protocol-custom-handler.php should help (if it doesn't, please let us know what's missing). Best Sebastian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Org protocol and new frame for remember
My apologies for the initial post fragment. (Note to self: C-c C-c binding for jumping to footnote reference does not work in Gnus!) Let's try this again: Hi all, I've recently begun to use org-protocol. I've been using it with the intriguing emacs-inspired browser Conkeror.[1] With the help of a nice blog post by Tassilo,[2] I have worked out a basic way to send snippets from the browser to remember via org-protocol. The great thing about Conkeror is that you can invoke org-remember the same way you do in emacs (either with M-x org-remember or, via a custom keybinding, with C-c r). I've posted my hacks at the bottom of the org-protocol page on Worg. Any advice/feedback would be greatly appreciated: http://orgmode.org/worg/org-contrib/org-protocol.php#conkeror-setup (My apologies to Sebastian if these should go somewhere else -- feel free to move them!) As I experiment with the fabulous org-protocol, I wonder whether I've missed a variable in org-protocol that tells the function org-protocol-remember to create a *temporary* new frame (i.e., one that pops up above the browser and then disappears after typing C-c C-c). I know I can set the variable remember-in-new-frame to t, but I would ideally like the new frame only for org-protocol-remember and not for other invocations of remember. My current solution is to advise the function org-protocol-remember (i.e., to set remember-in-new-frame locally for that function). But I thought it might be a nice addition to org-protocol if there were a variable that accomplishes this (e.g., org-protocol-remember-in-new-frame). I'd be eager to know if I am missing a current way to do this. Thanks, Matt Footnotes: [1] http://conkeror.org/ [2] http://tsdh.wordpress.com/2008/11/14/calling-org-remember-from-inside-conkeror/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol and encoding
Sebastian, Carsten, Carsten Dominik wrote: > Ulf, can you do some testing, please? done that using Emacs 23 (cvs today), Org (git today + patch), Firefox 3.0.8 on linux. Everything seems to work fine, I haven't found a single page/text that hasn't been encoded correctly. So I assume that the patch is working ... at least in the environment mentioned. Thanks for your effort and the good work :) Ulf ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol://remember:// question
Sebastian Rose writes: Hi Sebastian, > Yes. The best is to URL-encode the fields. Ok, no problem. I guess they're url-encoded when I get them inside Conkeror, anyway. Bye, Tassilo ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-protocol://remember:// question
Tassilo Horn writes:
> But one question remains. Do I have to do some special quoting in order
> to allow the protocol to split URL, TITLE and TEXT correctly? Let's say
> I do
>
> emacsclient -c \
> 'org-protocol:/remember:/http://www.google.de/the search engine/bla fasel
> bla'
>
> the link (%c) looks like [[http:][www.google.de]] which in not quite
> correct.
Yes. The best is to URL-encode the fields.
The slash is used as field separator for the following reason:
emacsclient compresses double or tripple slashes to one ("//" -> "/"),
which means those double slashes won't survive a call.
http://www.google.de/the search engine/
would become
http:/www.google.de/the search engine/
Hence we must encode slashes anyway. Double slashes are quite common on
web pages and could also reside in their titles.
But you could use any string as separator in custom handlers.
Best,
Sebastian
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-protocol://remember:// question
Sebastian Rose writes:
Hi Sebastian,
> the issue should be fixed now. The docs should now match the reality.
>
> Your templates may refer to the page title through
>
> %:description
>
> See
> http://orgmode.org/worg/org-contrib/org-protocol.php#example-template
> once it's updated.
Ok, now I use this template
("BROWSER" ?w "* BROWSER %:description\n (created: %U)\n\n %c\n\n %i")
and all fields are filled in. Thanks!
But one question remains. Do I have to do some special quoting in order
to allow the protocol to split URL, TITLE and TEXT correctly? Let's say
I do
emacsclient -c \
'org-protocol:/remember:/http://www.google.de/the search engine/bla fasel bla'
the link (%c) looks like [[http:][www.google.de]] which in not quite
correct.
Bye,
Tassilo
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
