From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: Encoding Problem in export? Date: Mon, 29 Jul 2013 12:29:29 +0530 Message-ID: <8738qxhmwe.fsf@gmail.com> References: <87bo5s27ey.fsf@sachwertpartner.de> <877ggg7suh.fsf@gmail.com> <51EF32F4.9030309@gmx.de> <87txjk5s2q.fsf@gmail.com> <87a9lcfg9g.fsf@gmail.com> <877ggg5i5q.fsf@gmail.com> <87y58vp9mj.wl%dmaus@ictsoc.de> <87li4u48jp.fsf@gmail.com> <87r4emdl2a.wl%dmaus@ictsoc.de> <87d2q54o7e.fsf@gmail.com> <87k3kc1n6f.wl%dmaus@ictsoc.de> <87iozwmf87.fsf@gmail.com> <87bo5n84ih.fsf@gmail.com> <87ehaj0vzu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3hOy-0000NO-GJ for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 02:58:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3hOp-000232-Sb for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 02:57:52 -0400 Received: from mail-pd0-x230.google.com ([2607:f8b0:400e:c02::230]:42572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3hOp-00022n-LO for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 02:57:43 -0400 Received: by mail-pd0-f176.google.com with SMTP id q10so1936596pdj.35 for ; Sun, 28 Jul 2013 23:57:42 -0700 (PDT) In-Reply-To: <87ehaj0vzu.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 28 Jul 2013 13:22:45 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: David Maus , emacs-orgmode@gnu.org, Nick Dokos Nicolas, David I just interjected. Nicolas Goaziou writes: > ...if that part cannot happen for some reason, links will be unusable > outside Org. Correctness should overrule compatibility. In practice, we may have to strike a balance, with more weight thrown in favor of correctness. I am stating the obvious here, but in a way that is practically useless to the discussion at hand. I trust that any solution that you come up with will be a good one. Also the timing is right. We can always say Org-8.0 makes a clear departure from earlier versions for reasons of robustness and correctness. ---------------------------------------------------------------- Speaking from gut (aka making things up) Link (un)escaping has also something to do with org-protocol and how the URL in browser's address bar is "captured", "encoded"(?) and "transferred" to the Emacs proper via the bookmarklet. So the browser (don't forget the clipboard) acts as *active* intermediaries as the URL makes it's way from the browser to the Org file either via hand or through emacsclient. To complicate the issue, browser being user facing may be expected to be very lenient with a URL or how it is "presented" to the user. ps-1: org-protocol to work on Windows is quite flaky. ps-2: There are frequent posts to Emacs mailing lists where copying from browser to a Emacs buffer will show up un-readable boxes. ---------------------------------------------------------------- Don't read further, if you are allergic to meta musings. As far as Org is concerned, backward compatibility is not a issue. The community is always being replaced *every* academic year. New scholars come and the old scholars leave. The only steady lot of the population is the college dons. They will not rely on Org *solely* for serious publishing work. They do revise their course support material - like beamer presentations etc - every term. In summary, shelf-life of an Org source file that is actually exported is unlikely to be beyond 4-5 years. The contents of such source file has less of stable parts and more of moving parts.