From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: Feature request: filling of long captions Date: Fri, 07 Feb 2014 11:12:23 +0100 Message-ID: <874n4btens.fsf@med.uni-goettingen.de> References: <87zjm4u1i7.fsf@med.uni-goettingen.de> <87lhxooclu.fsf@bzg.ath.cx> <84ha8bj3lz.fsf@gmail.com> <87d2izbr1c.fsf@gmail.com> <87ppmz1fob.fsf@gmail.com> <87a9e3cnse.fsf@bzg.ath.cx> <87ha8b1c0z.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBiQP-0000EM-Ms for emacs-orgmode@gnu.org; Fri, 07 Feb 2014 05:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBiQG-0005fa-Hp for emacs-orgmode@gnu.org; Fri, 07 Feb 2014 05:12:45 -0500 Received: from plane.gmane.org ([80.91.229.3]:41530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBiQG-0005el-B5 for emacs-orgmode@gnu.org; Fri, 07 Feb 2014 05:12:36 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WBiQF-0003K7-2l for emacs-orgmode@gnu.org; Fri, 07 Feb 2014 11:12:35 +0100 Received: from vpn-2122.gwdg.de ([134.76.2.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Feb 2014 11:12:35 +0100 Received: from andreas.leha by vpn-2122.gwdg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Feb 2014 11:12:35 +0100 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 Hello, Nicolas Goaziou writes: > Hello, > >> Nicolas, what do you think of enhancing the auto-filling (and >> delete-indentation) capabilities for some affiliated keywords? >> >> #+CAPTION: >> #+HEADER: >> #+TBLFM: > > Not that it matters much, but "TBLFM" is not an affiliated keyword per > se, it belongs to the table syntax. OTOH, you can have "CAPTION" and > "HEADER" keywords on top of almost any element type. > > Anyway, the three keywords are very different. > > To start with the one I know the most, CAPTION can have an optional > value, and multiple caption lines can have as many optional values. > > #+CAPTION[short caption]: long caption > #+CAPTION[short caption, continued]: long caption, continued. > > Therefore, filling it can be tricky since you have to pay attention to > both values. > > Moreover, if the "short" caption is too long to fit on one line, that > line still needs to end with "]:" to be valid. > > #+CAPTION[very very ... long "short" caption]: > #+CAPTION[continued even here]: long caption > #+CAPTION: long caption continued. > This is something, that I had not thought about when I expressed my wish. I did not even know, that consecutive #+CAPTION lines could also have consecutive short captions. I see the difficulty here. Usually, my votes are in favour of backwards compatibility. So, I am not too sure about this suggestion myself: But here an obvious 'solution' would be to move the short caption to #+SHORT_CAPTION. I see that such change would bring its own difficulties besides breaking the backwards compatibility. Like what to do when there is a short caption but no 'long' caption. I am just continuing this discussion, as I do not have 'the occasional three lines caption need' but the 'always multi-lines caption need'. In my opinion, images in an article/paper/thesis/... should tell their story independently of the text referring to them. So, my captions tend to be (too?) long. So, I would benefit a lot from whatever filling mechanism might get implemented. [...] Regards, Andreas