* Re: Some orgtbl doc issues
2013-08-30 16:46 ` Carsten Dominik
@ 2013-08-31 6:01 ` Rustom Mody
2013-08-31 16:32 ` Rustom Mody
1 sibling, 0 replies; 5+ messages in thread
From: Rustom Mody @ 2013-08-31 6:01 UTC (permalink / raw)
To: Carsten Dominik, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
Running just now... will answer in detail later
Just want to say for now that this was prompted by a discussion on python
list in which a half-dozen people expressed a wish for something like this.
Nobody seemed to know/mention org and since I could not work out all the
details, Ive not so far answered
On Fri, Aug 30, 2013 at 10:16 PM, Carsten Dominik <carsten.dominik@gmail.com
> wrote:
> Hi Rustom,
>
> thanks for this.
>
> On 16.8.2013, at 16:30, Rustom Mody <rustompmody@gmail.com> wrote:
>
> > Ive recently been poking around in orgtbl mode and encountered some
> > issues. Not sure how much is my own lack of understanding and how
> > much there are some little doc issues.
> >
> > 1 Option names dont match
> > =========================
> >
> > - Its orgtbl-radio-table-templates in emacs
> > - Its orgtbl-radio-tables in doc Appendix A.6.2
>
> Fixed, thanks.
>
> >
> >
> > 2 Receiving string
> > ==================
> >
> > - Seems to be "RECEIVE ORGTBL"
>
> It is BEGIN RECEIVE ORGTBL followed by a table name. As the example in
> the manual shows. Does this have to be more explicit?
>
> > - String seems to be hardwired. Which may be ok if its by design.
>
> Yes, hardwired by design.
>
> > - Not clear what is the relation of this string and
> > orgtbl-radio-templates
>
> The templates insert a BEGIN RECEIVE/END RECEIVE table template with
> *proper commenting* around it in different programming modes.
> I improved this in the docs.
>
> > - I find 1 space is fixed between RECEIVE and ORGTBL. Multiple
> > allowed between ORGTBL and table-name
>
> OK, I have removed this restriction.
>
> > - Its not clear from the doc whether its "RECEIVE ORGTBL" or
> > "/* RECEIVE ORGTBL"
>
> That depends on the programming mode. The documentation says that the
> lines must be comments in the current mode, I would think that this is
> clear enough.
>
> > - Subtle interaction between # in org and host mode comment char -- #
> > in python, shell etc -- could do with some elaboration
>
> Can you propose something for the documentation?
>
> >
> >
> > 3 hook system
> > =============
> >
> > - What are the hooks for orgtbl?
> > - How do the org hooks relate to the orgtbl hooks?
> > - Note: orgtbl is for those who are not otherwise using orgmode
>
> What to you mean? Mode hooks, or hooks for specific functionality of the
> table? If table commands run hooks, the corresponding trgtbl commands will
> do so as well, because they simply call the table functions in an
> environment where the proper keys bindings are not accessible.
>
> orgtbl-mode is a standard minor mode and has `orgtbl-mode-hook', similar
> to all other minor modes. See the documentation of define-minor-mode. Do
> you feel the manual should say so? It does not document many other hooks
> in org either, because there are too many.
>
>
> >
> > 4 Long header line
> > ==================
> >
> > I could not figure out how to split a long
> > :#+ORGTBL: SEND... line
>
> It cannot be split.
>
> Regards
>
> - Carsten
>
> >
> > Regards
> > Rusi
> >
>
>
--
http://www.the-magus.in
http://blog.languager.org
[-- Attachment #2: Type: text/html, Size: 4285 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Some orgtbl doc issues
2013-08-30 16:46 ` Carsten Dominik
2013-08-31 6:01 ` Rustom Mody
@ 2013-08-31 16:32 ` Rustom Mody
[not found] ` <EC962964-FF55-49D0-820C-C5642649E89A@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: Rustom Mody @ 2013-08-31 16:32 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4727 bytes --]
Well clearly the radio tables section reads better now. Further comments
inline.
Before that some general comments.
The Python list thread starting here
http://mail.python.org/pipermail/python-list/2013-July/653164.html
As you will see some python programmers (including emacsers!) seem to have
a need for something like this and dont seem to know about org. And by
extension one may assume other languages than python also. In short this
seems to be a general need.
So what is written below should be taken less from my own pov -- I am
hardly an org power-user but still a user -- than from the pov of a general
emacser -- a programmer who uses emacs and knows next to nothing about org
On Fri, Aug 30, 2013 at 10:16 PM, Carsten Dominik <carsten.dominik@gmail.com
> wrote:
> Hi Rustom,
>
> thanks for this.
>
> On 16.8.2013, at 16:30, Rustom Mody <rustompmody@gmail.com> wrote:
>
> > Ive recently been poking around in orgtbl mode and encountered some
> > issues. Not sure how much is my own lack of understanding and how
> > much there are some little doc issues.
> >
> > 1 Option names dont match
> > =========================
> >
> > - Its orgtbl-radio-table-templates in emacs
> > - Its orgtbl-radio-tables in doc Appendix A.6.2
>
> Fixed, thanks.
>
> >
> >
> > 2 Receiving string
> > ==================
> >
> > - Seems to be "RECEIVE ORGTBL"
>
> It is BEGIN RECEIVE ORGTBL followed by a table name. As the example in
> the manual shows. Does this have to be more explicit?
>
> > - String seems to be hardwired. Which may be ok if its by design.
>
> Yes, hardwired by design.
>
Not a problem in itself.
It becomes a problem in connection with the dfault value of
org-radio-table-templates which contains many instances of
BEGIN RECEIVE ORGTBL %n
and thereby suggests that that is changeable
> > - Not clear what is the relation of this string and
> > orgtbl-radio-templates
>
> The templates insert a BEGIN RECEIVE/END RECEIVE table template with
> *proper commenting* around it in different programming modes.
> I improved this in the docs.
>
> > - I find 1 space is fixed between RECEIVE and ORGTBL. Multiple
> > allowed between ORGTBL and table-name
>
> OK, I have removed this restriction.
>
> > - Its not clear from the doc whether its "RECEIVE ORGTBL" or
> > "/* RECEIVE ORGTBL"
>
> That depends on the programming mode. The documentation says that the
> lines must be comments in the current mode, I would think that this is
> clear enough.
>
Some languages (eg Python) have no multiline comment but have a multiline
string which is also ok to use
>
> > - Subtle interaction between # in org and host mode comment char -- #
> > in python, shell etc -- could do with some elaboration
>
> Can you propose something for the documentation?
>
> >
> >
> > 3 hook system
> > =============
> >
> > - What are the hooks for orgtbl?
> > - How do the org hooks relate to the orgtbl hooks?
> > - Note: orgtbl is for those who are not otherwise using orgmode
>
> What to you mean? Mode hooks, or hooks for specific functionality of the
> table? If table commands run hooks, the corresponding orgtbl commands will
> do so as well, because they simply call the table functions in an
> environment where the proper keys bindings are not accessible.
>
As I said at start of this mail, we are looking at orgtbl for otherwise
non-org users.
For that audience I was exploring whether vanilla org would work OTB
ie without any of my org-settings
also not the latest but one bundled with emacs
Since at that point I really could not understand
orgtbl-radio-table-templates and thought it had to be set I asked. As it
appears now, it works without any customization so the point is moot.
Nevertheless the general question is: If a non-org user of orgtbl needs to
set up minor-mode specific customization where is it to be done?
> orgtbl-mode is a standard minor mode and has `orgtbl-mode-hook', similar
> to all other minor modes. See the documentation of define-minor-mode. Do
> you feel the manual should say so? It does not document many other hooks
> in org either, because there are too many.
>
>
> >
> > 4 Long header line
> > ==================
> >
> > I could not figure out how to split a long
> > :#+ORGTBL: SEND... line
>
> It cannot be split.
>
There are programming related organizations for which something like
80-char lines is really not negotiable!
So I hope this can be considered as a feature request of course a very
minor one
Regards
>
> - Carsten
>
Speaking generally, maybe someone should respond to that python list thread.
It can be me however someone more org-knowledgeable may be more appropriate
:-)
Thanks and regards
Rusi
--
http://blog.languager.org
[-- Attachment #2: Type: text/html, Size: 6910 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread