Possible bugs

Possible bugs

[Bastien]

Hi Dominik and all,

Thanks for org-mode.  Here is a quite long list of possible bugs or
strange behavior.

* Fontification: a *bold* is not recognized as such when other than a
  space or a beginning-of-line char surrounds it.  Hence "(*bold*)" or
  "*bold*?" are not fontified.

  Additionnally: "*bold*" at the beginning of a line is also fontified
  with org-level-* face. Maybe org-level-* regexps should made a space
  after the "*" mandatory.

* No comment syntax is defined - "#" seems obvious.

* DEADLINE/SCHEDULED strings still matched when commented.

* The ?" char acceptable in links, which sometimes produces strange
  results. 

* When TYP_SEQ and TODO_SEQ both end with "TODO" (as they should do),
  then `C-c a t' two redundant "DONE" options.

* Maybe links in fixed-width environments should be either expanded or
  underlined (except if you got rid of every kind of fontification in
  this environment).

* org-store link corrupting gnus-registry ?  I'm using gnus-registry
  and i did remark that org-store-link, when called on an article,
  corrupted the ~/.gnus.registry.el file.  I've no further hint on
  *when* and *why* it happens.  Seems quite random for now.

* Storing an image buffer with `org-store-link' stores the image
  itself (as a read-only object).  I think it would be more convenient
  to have the file-name stored instead of the image.

Well... enough for today!  Hope this is useful.

Best regards,

-- 
Bastien

Re: Possible bugs

[Carsten Dominik]

Hi Bastien,
On Jun 10, 2006, at 14:24, Bastien wrote:

> Hi Dominik and all,

(Carsten is my first name...)

Thanks for this very useful list of bugs and other issues.  I'll go 
through these for the next release.

- Carsten

>
> Thanks for org-mode.  Here is a quite long list of possible bugs or
> strange behavior.
>
> * Fontification: a *bold* is not recognized as such when other than a
>   space or a beginning-of-line char surrounds it.  Hence "(*bold*)" or
>   "*bold*?" are not fontified.
>
>   Additionnally: "*bold*" at the beginning of a line is also fontified
>   with org-level-* face. Maybe org-level-* regexps should made a space
>   after the "*" mandatory.
>
> * No comment syntax is defined - "#" seems obvious.
>
> * DEADLINE/SCHEDULED strings still matched when commented.
>
> * The ?" char acceptable in links, which sometimes produces strange
>   results.
>
> * When TYP_SEQ and TODO_SEQ both end with "TODO" (as they should do),
>   then `C-c a t' two redundant "DONE" options.
>
> * Maybe links in fixed-width environments should be either expanded or
>   underlined (except if you got rid of every kind of fontification in
>   this environment).
>
> * org-store link corrupting gnus-registry ?  I'm using gnus-registry
>   and i did remark that org-store-link, when called on an article,
>   corrupted the ~/.gnus.registry.el file.  I've no further hint on
>   *when* and *why* it happens.  Seems quite random for now.
>
> * Storing an image buffer with `org-store-link' stores the image
>   itself (as a read-only object).  I think it would be more convenient
>   to have the file-name stored instead of the image.
>
> Well... enough for today!  Hope this is useful.
>
> Best regards,
>
> -- 
> Bastien
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: Possible bugs

[Carsten Dominik]

On Jun 10, 2006, at 14:24, Bastien wrote:

> Hi Dominik and all,
>
> Thanks for org-mode.  Here is a quite long list of possible bugs or
> strange behavior.
>
> * Fontification: a *bold* is not recognized as such when other than a
>   space or a beginning-of-line char surrounds it.  Hence "(*bold*)" or
>   "*bold*?" are not fontified.

FOr the coming release I have generalized the emphasis part very much 
and allowed to configure the regular expression for emphasis matching.  
The cases you mention above are now covered - I am always hesitant to 
make make it match too easily because it may match in unwonted places.  
But maybe I am too restrictive.  You are welcome to suggest a better 
default for the customization variable org-emphasis-regexp-components 
after the next release.

>
>   Additionnally: "*bold*" at the beginning of a line is also fontified
>   with org-level-* face. Maybe org-level-* regexps should made a space
>   after the "*" mandatory.

This is already on my list, but takes longer because headline matching 
happens in a million places in the Org-mode code, in many different 
ways.  For me personally, this is usually not a problem  because I like 
to indent text under a headline, so that a *bold* is usually not at the 
beginning of the line.  But yes, this should be fixed eventually.
>
> * No comment syntax is defined - "#" seems obvious.

How could I miss this????  Thanks.

>
> * DEADLINE/SCHEDULED strings still matched when commented.

Hmmm, yes this is true.  I never use comments in org-mode to turn off 
timestamps and their function.  For now, I am not going to fix this.

>
> * The ?" char acceptable in links, which sometimes produces strange
>   results.

Example?

>
> * When TYP_SEQ and TODO_SEQ both end with "TODO" (as they should do),
>   then `C-c a t' two redundant "DONE" options.

You should never have both in a buffer, just one is allowed.  The 
result of putting both is not well defined.

> * Maybe links in fixed-width environments should be either expanded or
>   underlined (except if you got rid of every kind of fontification in
>   this environment).

This is really for quoting stuff, so I guess the bug is that font-lock 
still fontifies in these areas.

I am taking note, but need time to fix this.

>
> * org-store link corrupting gnus-registry ?  I'm using gnus-registry
>   and i did remark that org-store-link, when called on an article,
>   corrupted the ~/.gnus.registry.el file.  I've no further hint on
>   *when* and *why* it happens.  Seems quite random for now.

Any gnus expert around here?  I have not idea why and how this might 
happen.

>
> * Storing an image buffer with `org-store-link' stores the image
>   itself (as a read-only object).  I think it would be more convenient
>   to have the file-name stored instead of the image.

What is an image buffer?  I buffer visiting a (for example) .jpg file?

>
> Well... enough for today!  Hope this is useful.

Certainly is.  Thanks.

- Carsten

Re: Possible bugs

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

> FOr the coming release I have generalized the emphasis part very much
> and allowed to configure the regular expression for emphasis matching.

Works far better for me like this.  I don't see any relevant
improvement to org-emphasis-regexp-components.  (BTW, I've made
org-blog to use org-emph-re instead of org-bold-re and the like.)

Trying to customize org-emphasis-alist to use strike-through
fontification, i've been manually setting this:

(setq org-emphasis-alist
  '(("*" bold "<b>" "</b>")
    ("/" italic "<i>" "</i>")
    ("_" underline "<u>" "</u>")
    ("=" shadow "<code>" "</code>")
    ("+" (:strike-through t) "<code>" "</code>")))

Which works great.

But doing the same from M-x customize-variable RET org-emphasis-alist
does not work, since (:strike-through t) is not recognize here as a
face.

> This is already on my list, but takes longer because headline matching
> happens in a million places in the Org-mode code, in many different
> ways.  For me personally, this is usually not a problem  because I
> like to indent text under a headline

Same for me - till i needed to write the org file for org-blog ;)

>> * The ?" char acceptable in links, which sometimes produces strange
>>   results.

If someone quotes a link "http://like.this" then the last `"' is
fontified as part of the link.

> You should never have both in a buffer, just one is allowed.  The
> result of putting both is not well defined.

Okay.  Using both was quite natural to me, and no strange behavior so
far.  

> Any gnus expert around here?  I have not idea why and how this might
> happen.

I'm not a Gnus expert but i'll try to track down this bug further.  
I let you know.

> What is an image buffer?  I buffer visiting a (for example) .jpg
> file? 

Yes.  IMHO org-store-link in such a buffer should only store the
*file*, without inserting the image itself in the link.

-- 
Bastien

Re: Possible bugs

[Carsten Dominik]

Hi Bastien,

On Jun 10, 2006, at 18:20, Bastien wrote:

> Trying to customize org-emphasis-alist to use strike-through
> fontification, i've been manually setting this:
>
> (setq org-emphasis-alist
>   '(("*" bold "<b>" "</b>")
>     ("/" italic "<i>" "</i>")
>     ("_" underline "<u>" "</u>")
>     ("=" shadow "<code>" "</code>")
>     ("+" (:strike-through t) "<code>" "</code>")))

I had no idea that this might work, this is great, thanks for pointing 
this out.  I'll fix the customization code to accept this.


>
>>> * The ?" char acceptable in links, which sometimes produces strange
>>>   results.
>
> If someone quotes a link "http://like.this" then the last `"' is
> fontified as part of the link.

I guess quotes are allowed as parts of a link, so there is no way I 
could tell, could I?
A workaround would be to write "[[http://like.this]]".
What does this have to do with the question mark?

>
>> You should never have both in a buffer, just one is allowed.  The
>> result of putting both is not well defined.
>
> Okay.  Using both was quite natural to me, and no strange behavior so
> far.

What "natural" behavior would you have expected by having both?  Maybe 
there is a good way to define what should happen in this case?

>
>> Any gnus expert around here?  I have not idea why and how this might
>> happen.
>
> I'm not a Gnus expert but i'll try to track down this bug further.
> I let you know.

Thanks.

>
>> What is an image buffer?  I buffer visiting a (for example) .jpg
>> file?
>
> Yes.  IMHO org-store-link in such a buffer should only store the
> *file*, without inserting the image itself in the link.

OK, I will do this.  I guess these would be buffers in `image-mode'.

- Carsten

Re: Possible bugs

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

> I had no idea that this might work, this is great, thanks for pointing
> this out.  I'll fix the customization code to accept this.

« Good software works great in some ways that we didn't even
anticipate. » (from fuzzy memory - Eric S. Raymond?)

> I guess quotes are allowed as parts of a link, so there is no way I
> could tell, could I?

Maybe just modify org-non-link-chars?

(defconst org-non-link-chars "]\t\n\r<>\"")
                                       ^^

> What does this have to do with the question mark?

(I was just using elisp syntax for a character: " -> ?")

> What "natural" behavior would you have expected by having both?
> Maybe there is a good way to define what should happen in this case?

Cycling through a heading with both SEQ_TODO and TYP_TODO defined
first cycles through the SEQ_TODO keywords.  After the first "DONE" 
it cycles through the TYP_TODO till the next "DONE".

I'm using it when i need to categorize a task without tagging it.  But
my use of org-mode is currently quite unstable, i'm just trying to
figure out what is the best way to get things appropriatly ordered.

>> I'm not a Gnus expert but i'll try to track down this bug further.
>> I let you know.

I think this comes from the fact that org-store-link doesn't strip
strings off their fontifications.  See the way an registry entry
looks in my ~/.gnus.registry.el:

<http://www.cognition.ens.fr/~guerry/org-b-log/org-gnus-registry.txt>

This causes gnus-registry.el to complain, because of the wrong "#"
character.

> OK, I will do this.  I guess these would be buffers in `image-mode'.

Right.

Regards,

-- 
Bastien