From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: Tabular overview of org-element.el Date: Sat, 20 Apr 2013 22:45:53 +0200 Message-ID: <87bo993p8e.fsf@gmail.com> References: <87obd944dk.fsf@gmail.com> <87ip3hnou6.fsf@gmail.com> <87k3nx3yz5.fsf@gmail.com> <87ehe5nlnh.fsf@gmail.com> <87fvyl3use.fsf@gmail.com> <87li8dkom9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTefb-0005Jp-KP for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 16:46:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTefa-0001Pr-PK for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 16:46:03 -0400 Received: from plane.gmane.org ([80.91.229.3]:59919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTefa-0001Pi-Hi for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 16:46:02 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UTefY-00042T-B6 for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 22:46:00 +0200 Received: from e178055128.adsl.alicedsl.de ([85.178.55.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Apr 2013 22:46:00 +0200 Received: from tjolitz by e178055128.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Apr 2013 22:46:00 +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: emacs-orgmode@gnu.org Nicolas Goaziou writes: >> To keep the system consistent, there should be two types of link objects >> ('plain-link' and 'decorated-link') that are both successors too, and >> maybe additionally a successor category 'link' that can be applied when >> distinction between the two link object-types does not matter. > > That's what I talked about indeed, but besides consistency, there's not > much benefit to do that. I'd rather have images as full-fledged objects, > something like: > > [img:"...."] > > which could possibly be extended with properties for export: > > [img:"...." :prop1 val1 :prop2 val2] That sounds like a very good idea to me, from the point of view of a user, and from the point of view of somebody who tries to understand the system you used for modeling Org files. And consistency can turn out very beneficial in the long run, even if the benefits are not so obvious at the moment. -- cheers, Thorsten