From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: text color + highlight Date: Wed, 11 Aug 2010 02:48:17 -0400 Message-ID: <877hjx4pce.fsf@stats.ox.ac.uk> References: <87pqxw5cb1.fsf@gnu.org> <87mxszcsuv.fsf@gmail.com> <87d3tvru38.fsf@gmail.com> <87iq3kkef1.fsf@gmail.com> <4C60EE48.6030106@christianmoe.com> <532CED92-88AD-46F6-BC67-9D0DEDAA6D71@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=49700 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oj56w-00052n-K7 for emacs-orgmode@gnu.org; Wed, 11 Aug 2010 02:48:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oj56v-0007LZ-1e for emacs-orgmode@gnu.org; Wed, 11 Aug 2010 02:48:26 -0400 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:57456) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oj56u-0007LA-PC for emacs-orgmode@gnu.org; Wed, 11 Aug 2010 02:48:25 -0400 In-Reply-To: <532CED92-88AD-46F6-BC67-9D0DEDAA6D71@gmail.com> (Carsten Dominik's message of "Tue, 10 Aug 2010 09:06:38 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: Bastien , emacs-orgmode@gnu.org, mail@christianmoe.com, Vinh Nguyen Carsten Dominik writes: > Hi, > > Can we please first read Samuels post about extensible syntax? Before > we invent 20 other new syntaxes? > > http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10204 May I add this thread to the discussion as an example of another feature that was suggested as a possible use case for extensible syntax: http://thread.gmane.org/gmane.emacs.orgmode/24431 This is the feature I currently want most in org-mode: org mode blocks that behave exactly like org-mode blocks, except that their content in reality lies in a different file. This would allow org-mode to improve on its claim of inobtrusiveness: one could collaborate on a code project without the other people knowing you were using org-mode to manage your access points into the shared files. Also, I like the corollary, that a version control system will track the code content in separate files from the org content. A related idea is having links with both a start and an end point: following them would end up in a buffer to the specified region ("window links" if window wasn't already used for a different meaning). Any ideas welcome! (there are also ideas in that thread) Dan > Thanks! > > On Aug 10, 2010, at 8:14 AM, Christian Moe wrote: > >> Hi, >> >> >> >> >> - this would be extensible, e.g. >> >> >> >> [background[yellow] highlighted text] >> >> >> >> could export to the following html >> >> >> >> highlighted text >> >> >> >> - this would avoid "{}"s >> >> >> >> - this would look more "org-like" than the pure latex solution >> >> >> >> the only issue with the above is that it may conflate a new / >> markup/ >> >> syntax with org-mode's existing /link/ syntax. >> >> >> >> Thoughts? -- Eric >> >> I'd like an extensible inline markup construct (not primarily for >> coloring). >> >> Would it make sense to hijack custom links for this purpose, and use >> existing bracketed link syntax rather than add a new syntax? >> >> For semantic tagging (my chief interest), one might e.g. define a >> class' link type and an HTML export handler to wrap the contents in >> tags. >> >> : [[class:animals][some text about animals]] >> >> As for color: If one is satisfied with getting colors on export, >> defining a `color' link type and appropriate export handlers will >> do. >> >> : [[color:red][some colored text]] >> >> If one also wants the text to appear in the right color within Org- >> mode, and does not want the pseudo-link markup to be underlined and >> look like links, it would require additional Org functionality (I >> think): User-defined custom faces for different link types. >> >>>>> What syntax to use... >>>> >>>> I've thought briefly about the following syntax >>>> >>>> [color[red] text to be colored red] >>> Nope, I am against this syntax. If we introduce a more general >>> syntax, >>> then it should be done in the way Samuel proposed. WHich means >>> we firs get a keyword indtroducing the piece, and then properties. >>> Like >>> $[style :color red the red text] >>> or >>> $[face :color :italic t red the red text] >>> Something like the $ before "[" also would seem critical to >>> disambiguate >>> from other uses of "[". >>> However, I am not too excited about extra syntax to get this kind >>> of thing. >>> Would not oppose it, but probably never use it. >>> - Carsten >> >> Those examples are not very readable IMO -- without a separator it's >> hard to see where the property values end and the marked up text >> begins. >> >> Yours, >> Christian > > - Carsten > > > > > _______________________________________________ > 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