Hello,
Thorsten Jolitz writes:
> I noticed this issue again when calling `org-element-at-point` with
> point before the stars in
>
> ,
> | ** [#A] whatsup :mytag:it:
> | hello world
> `
>
> in an emacs-lisp-mode buffer - it results in:
>
> ,
> | (paragraph (:begin 193 :end 246 :cont
Nicolas Goaziou writes:
> Hello,
>
> Thorsten Jolitz writes:
>
>> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
>> mandatory,
>
> No, it isn't.
>
>> couldn't a more robust construct be used, either something
>> like this (untested) regexp:
>>
>> ,
>> | "[^[:space:]\\n]
Nick Dokos writes:
> Nick Dokos writes:
>
>> Sebastien Vauban
>> writes:
>>
>>> Nick Dokos wrote:
Thorsten Jolitz writes:
> Thorsten Jolitz writes:
>
> As a side-remark, I did send these blocks with emptly lines between them,
> and when I look at my post in gmane the form
Nicolas Richard writes:
> Thorsten Jolitz writes:
>> Maybe they switched to the new parser between versions, that parses a
>> src-block with :post-blank's, but does not take them into account when
>> interpreting?
>
> I tried an experiment : (defun org-mode (&rest _) t) and refresh. The
> newli
Nicolas Richard writes:
> I would like to blame (mm-uu-dissect) but I didn't look into it.
I now blame (mm-uu-dissect). The following patch fixes it, but that part
of the code must be there for a reason... and I don't know what it is.
Modified lisp/gnus/mm-uu.el
diff --git a/lisp/gnus/
Thorsten Jolitz writes:
> Maybe they switched to the new parser between versions, that parses a
> src-block with :post-blank's, but does not take them into account when
> interpreting?
I tried an experiment : (defun org-mode (&rest _) t) and refresh. The
newlines didn't come back (but fontificat
Nicolas Goaziou writes:
> AFAIK, [:space:] is not compatible with XEmacs.
FWIW, I'm less and less sure why we should worry about XEmacs
compatibility. I wish some XEmacs user could step up and take
care of all these XEmacs compatibility issue.
--
Bastien
Thorsten Jolitz writes:
> Nick Dokos writes:
>
>> Nick Dokos writes:
>>
>>> Sebastien Vauban
>>> writes:
>>>
Nick Dokos wrote:
> Thorsten Jolitz writes:
>> Thorsten Jolitz writes:
>>
>> ...
>> Am I the only one seeing this? Bug in gnus/message mode?
>
> I see
Nicolas Richard writes:
> Nick Dokos writes:
>> One machine is running Gnus v. 5.13: that one smooshes the code
>> blocks together.
>>
>> The other is running Ma Gnus v. 0.12: that one leaves empty
>> lines between blocks.
>
> Do they both fontify blocks ?
Yes.
--
Nick
Nick Dokos writes:
> Nick Dokos writes:
>
>> Sebastien Vauban
>> writes:
>>
>>> Nick Dokos wrote:
Thorsten Jolitz writes:
> Thorsten Jolitz writes:
>
> As a side-remark, I did send these blocks with emptly lines
> between them,
> and when I look at my post in gmane th
Nick Dokos writes:
> One machine is running Gnus v. 5.13: that one smooshes the code
> blocks together.
>
> The other is running Ma Gnus v. 0.12: that one leaves empty
> lines between blocks.
Do they both fontify blocks ?
--
Nico.
Nick Dokos writes:
> Sebastien Vauban
> writes:
>
>> Nick Dokos wrote:
>>> Thorsten Jolitz writes:
Thorsten Jolitz writes:
As a side-remark, I did send these blocks with emptly lines between them,
and when I look at my post in gmane the format looks alright, however
wh
Thorsten Jolitz writes:
> Rasmus writes:
>
> Hi Rasmus,
>
>> Thorsten Jolitz writes:
>>
>>> As a side-remark, I did send these blocks with emptly lines between them,
>>> and when I look at my post in gmane the format looks alright, however
>>> when I open it in gnus the empty lines are gone and
Rasmus writes:
Hi Rasmus,
> Thorsten Jolitz writes:
>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this:
>
> Do you by an
Rasmus writes:
> Thorsten Jolitz writes:
>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this:
>
> Do you by any chance hav
Hi Thorsten,
Thorsten Jolitz writes:
> As a side-remark, I did send these blocks with emptly lines between them,
> and when I look at my post in gmane the format looks alright, however
> when I open it in gnus the empty lines are gone and it looks like this:
Do you by any chance have `gnus-arti
Nicolas Goaziou writes:
> Hello,
>
> Thorsten Jolitz writes:
>
>> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
>> mandatory,
>
> No, it isn't.
>
>> couldn't a more robust construct be used, either something
>> like this (untested) regexp:
>>
>> ,
>> | "[^[:space:]\\n]
Hello,
Thorsten Jolitz writes:
> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
> mandatory,
No, it isn't.
> couldn't a more robust construct be used, either something
> like this (untested) regexp:
>
> ,
> | "[^[:space:]\\n]+"
> `
AFAIK, [:space:] is not compati
Sebastien Vauban
writes:
> Nick Dokos wrote:
>> Thorsten Jolitz writes:
>>> Thorsten Jolitz writes:
>>>
>>> As a side-remark, I did send these blocks with emptly lines between them,
>>> and when I look at my post in gmane the format looks alright, however
>>> when I open it in gnus the empty li
Nicolas Richard writes:
>> Although Org functions are of course made only for working in org-mode
>> and its a bit hard to see at first sight how this could be useful, I
>> wonder if the regexps could be made a bit more general to make
>> `org-element-at-point' work in programming modes too (most
Nick Dokos wrote:
> Thorsten Jolitz writes:
>> Thorsten Jolitz writes:
>>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this
Thorsten Jolitz writes:
> Am I the only one seeing this? Bug in gnus/message mode?
I also see the problem. I suspect that it happens when Gnus fontifies
the blocks. Doing "C-u g" shows that the "source" of the message is
correct (i.e. has the newlines).
--
Nico.
> Although Org functions are of course made only for working in org-mode
> and its a bit hard to see at first sight how this could be useful, I
> wonder if the regexps could be made a bit more general to make
> `org-element-at-point' work in programming modes too (most likely this
> behaviour is ca
Thorsten Jolitz writes:
> Thorsten Jolitz writes:
>
> As a side-remark, I did send these blocks with emptly lines between them,
> and when I look at my post in gmane the format looks alright, however
> when I open it in gnus the empty lines are gone and it looks like this:
>
>> * ORG SCRATCH
>>
Thorsten Jolitz writes:
As a side-remark, I did send these blocks with emptly lines between them,
and when I look at my post in gmane the format looks alright, however
when I open it in gnus the empty lines are gone and it looks like this:
> * ORG SCRATCH
>
> #+BEGIN_QUOTE
> hallo world
> #+END_
Hi List,
with point at the beginning of each of the following blocks,
`org-element-at-point' does recognize the correct type when buffer is in
org-mode and other text-modes, but not so in programming modes, e.g. the
*scratch* buffer (lisp-interaction-mode). Then only the src-block is
recognized c
26 matches
Mail list logo
