Nicolas Goaziou writes:
> Anyway, in this particular case, I guess we could consider comments as
> a stack of one line elements. I added the feature.
Thanks!
--
Bastien
Hello,
Bastien writes:
> I see that turning a commented line is prevented, while turning
> several commented lines is allowed. This feels weird. I don't
> think we should prevent this.
>
> What do you think?
I don't think there's much point in comparing function's behaviours when
acting on a
Hi Nicolas,
Nicolas Goaziou writes:
> True. I also allowed to turn one-line elements (keywords, clock,
> planning) into fixed-width areas.
I see that turning a commented line is prevented, while turning
several commented lines is allowed. This feels weird. I don't
think we should prevent this
Hello,
Bastien writes:
> I don't think we should prevent users to convert a headline into a
> fixed-width line.
True. I also allowed to turn one-line elements (keywords, clock,
planning) into fixed-width areas.
> Also, better to use the IGNORE-INVISIBLE arg of
> org-move-to-column IMO.
Done.
Nicolas Goaziou writes:
> Here is the function. If it is good enough, I'll add tests and wrap it
> up in a patch.
I don't think we should prevent users to convert a headline into a
fixed-width line. Also, better to use the IGNORE-INVISIBLE arg of
org-move-to-column IMO.
Otherwise works fine, t
Nicolas Goaziou writes:
> It is clearer now, thank you. I'll send a patch later on the ML.
Here is the function. If it is good enough, I'll add tests and wrap it
up in a patch.
#+begin_src emacs-lisp
(defun org-toggle-fixed-width ()
"Toggle fixed-width markup.
Add or remove fixed-width marku
Bastien writes:
> The baseline is this:
>
> - always consider regions made of whole lines
>
> - when all lines are fixed-width in the region, C-c : converts them to
> regular text
>
> - when zero or more (but not all) lines are fixed-width, converts all
> lines to fixed-width lines, ignoring
Nicolas Goaziou writes:
> Will
>
> : and some fixed line
> Some text
>
> also become
>
> : and some fixed line
> : Some text
>
> ?
Yes, if beg and end of the region are in each of those two lines.
> And what about headlines, e.g.
>
> : and some fixed line
>
> * Headline
>
> Some t
Bastien writes:
> No -- sorry. My suggestion is that this region
>
> Some text
> : and some fixed line
>
> becomes
>
> : Some text
> : and some fixed line
>
> If people want the behavior you describe, then using `C-x r t'
> will do. Otherwise, they will want the whole region to be conve
Hi Nicolas,
Nicolas Goaziou writes:
> So, to be clear, assuming the region encompasses everything,
>
> : text
> : text
>
> * Headline
>
> paragraph
> paragraph
>
> becomes
>
> : : text
> : : text
> :
> : * Headline
> :
> : paragraph
> : paragraph
>
> and
>
> paragraph
Hello,
Bastien writes:
> Nicolas Goaziou writes:
>> What happens if the region contains both a fixed-width area and
>> regular lines ?
>
> The same than when there is no fixed-width area: we convert the region
> into fixed-width. Then converting back to a regular area will be easy
> enough, a
Hi Nicolas,
Nicolas Goaziou writes:
> For example, without a region, and not at an example block, it would
> probably turn the current line into a fixed-width area line.
Yes.
> But that doesn't make sense if the line is in a verbatim area, e.g.,
> an example block. An error could be returned t
Hello,
Bastien writes:
> Yes, that'd be nice, thanks.
Then it would be good to define precise specifications for it.
For example, without a region, and not at an example block, it would
probably turn the current line into a fixed-width area line. But that
doesn't make sense if the line is in a
Hi Nicolas,
Nicolas Goaziou writes:
> Anyway, I removed it because, even if we want to keep it, it needs to be
> rewritten, using parser and unit tests. It also needs to be renamed.
>
> If we don't need C-c : binding, it is possible to re-implement it.
Yes, that'd be nice, thanks.
--
Bastien
Hello,
Bastien writes:
> I don't think `org-toggle-fixed-width-section' should be deleted
> entirely, as fixed-width text is still supported in this form:
>
> : Some text
>
> and using C-c : is very handy.
>
> What do you think?
I tend to use rectangular regions for that.
Anyway, I removed it
Hi Nicolas,
Nicolas Goaziou writes:
>> I'm for pushing the change to master
>
> Done
I don't think `org-toggle-fixed-width-section' should be deleted
entirely, as fixed-width text is still supported in this form:
: Some text
and using C-c : is very handy.
What do you think?
--
Bastien
Hi Nicolas,
Nicolas Goaziou writes:
>> I'm for pushing the change to master
>
> Done
Thanks!
>> and documenting this feature in maint as being obsolete.
>
> I added a few notes in ORG-NEWS. Feel free to complete them.
I will review ORG-NEWS before the next release, thanks.
--
Bastien
Hello,
Bastien writes:
> I'm for pushing the change to master
Done
> and documenting this feature in maint as being obsolete.
I added a few notes in ORG-NEWS. Feel free to complete them.
Regards,
--
Nicolas Goaziou
Hi Nicolas,
Nicolas Goaziou writes:
> There seems to be a consensus around it. The last question is: master or
> maint?
I'm for pushing the change to master and documenting this feature in
maint as being obsolete.
> It's not a bugfix, more like a spring clean, but there's a risk of
> having an
Hello,
Carsten Dominik writes:
> On 26 Jan 2014, at 23:03, Bastien wrote:
>
>> I think removing QUOTE won't hurt that much.
>
> I agree. I would also like to see it removed.
There seems to be a consensus around it. The last question is: master or
maint?
It's not a bugfix, more like a spring
"Sebastien Vauban"
writes:
> Of course, we can wonder whether that particularity of COMMENT couldn't
> or shouldn't be transported to :noexport: as well (or something extra,
> such a :donothing:).
A :donothing tag or property seems more logical to me than a COMMENT
keyword that is somehow a spec
Nick Dokos wrote:
> Bastien writes:
>
>> PS: Removing COMMENT would be more problematic, as it is very handy
>> to temporarily prevent a section from being exported or tangled.
>
> Doesn't a :noexport: tag do exactly that? (not sure about tangling
> actually, but that should be not be a big proble
On 26 Jan 2014, at 23:03, Bastien wrote:
> Hi Nicolas,
>
> I think removing QUOTE won't hurt that much.
I agree. I would also like to see it removed.
>
> PS: Removing COMMENT would be more problematic, as it is very handy
> to temporarily prevent a section from being exported or tangled.
W
Nick Dokos writes:
> Bastien writes:
>
>> PS: Removing COMMENT would be more problematic, as it is very handy
>> to temporarily prevent a section from being exported or tangled.
>
> Doesn't a :noexport: tag do exactly that? (not sure about tangling
> actually, but that should be not be a big pro
Bastien writes:
> PS: Removing COMMENT would be more problematic, as it is very handy
> to temporarily prevent a section from being exported or tangled.
Doesn't a :noexport: tag do exactly that? (not sure about tangling
actually, but that should be not be a big problem.) Why are two
mechanisms n
Hi Nicolas,
I think removing QUOTE won't hurt that much.
PS: Removing COMMENT would be more problematic, as it is very handy
to temporarily prevent a section from being exported or tangled.
--
Bastien
My guess is that quote should go. Does anybody use it?
I'd strongly want to keep comment, however, if that were questioned.
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Denmark: free Karina Hansen N
Rasmus writes:
> Nicolas Goaziou writes:
>
>> Alternatives:
>>
>> - Treat their contents as `quote-blocks' instead of `example-block'
>> - Remove them altogether, since they don't bring anything new.
>>
>> As a side note, if they are here to stay, it would be good to document
>> them.
>>
>> WD
Nicolas Goaziou writes:
> Alternatives:
>
> - Treat their contents as `quote-blocks' instead of `example-block'
> - Remove them altogether, since they don't bring anything new.
>
> As a side note, if they are here to stay, it would be good to document
> them.
>
> WDYT?
I'd be happy to see it g
Aloha Nicolas,
Nicolas Goaziou writes:
> At the moment, they are parsed specially by Org Elements, but I think it
> is a mistake. Like "COMMENT" keyword in headlines, "QUOTE" is more an
> instruction for the export framework. Therefore, they should be parsed
> as regular sections, and treated sp
Hello,
Quote sections are special sections triggered when their headline
container has the "QUOTE" keyword in it:
* QUOTE Headline
This is a quote section.
They are inherited (as many other things) from the previous export
framework. The behaviour of this keyword in undocumented in Org ma
31 matches
Mail list logo
