emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Torsten Wagner <torsten.wagner@gmail.com>
To: Carsten Dominik <drostekirsten@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>,
	Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: [RFC] Change some defcustoms into defcont
Date: Tue, 22 Oct 2013 20:28:37 +0200	[thread overview]
Message-ID: <CAPaq-gMKHD6NyJVfoyMC2hXogD+WGrujK1CRt=+=2-DWpAqNwg@mail.gmail.com> (raw)
In-Reply-To: <9ED40360-BFB2-4F8C-BADB-6F0A798C9742@gmail.com>

Hi,
not being a dev and really not being a lisp programmer, I still can
see Nicolas attempt to unify the syntax in a way "all and
everyone/everything" can rely on it. The question would be what would
be more troublesome? Dealing in future with people who by chance
changed some of those variables and who suddenly face problems using
third party (internal as well as external) tools. E.g., tools like
org-ruby came to my mind. More and more projects start to include
org-syntax too. For all those it would become difficult to rely on
certain keywords.
Or is it more problematic that those who changed variables already,
might find there system broken / in need of manual adoption after an
update?

Anyhow, I just had this idea that org-mode could rely on a fixed (as
written in stone) set of keywords and that an a new exporter backend
will be introduced which simply creates a standard-conform org-mode
file. Let's call it ox-legacy ;)  Those created files could be send to
others to work on it or could be used in conjunction with 3rd party
programs.
By time, one could think of a org-mode import, which again takes a
standard conform org-mode file and translates it back into the
individual settings of a specific user.

Having an legacy org-mode exporter and importer, could even allow to
customize org-mode for different languages, e.g. one could set (setq
org-mode-language "german") to get a set of keywords in German.
Exporting it into legacy org-mode would translate it back into e.g.
English, which then again could be read-in by a user who set (setq
org-mode-language "japanese") and who would be able to read the file
with a set of Japanese keywords.

Just an idea I had following this thread.

All the best

Torsten


On 22 October 2013 12:34, Carsten Dominik <drostekirsten@gmail.com> wrote:
>
> On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>> Hello,
>>
>>> You also said things like
>>>
>>>> That's exactly the point of the defconst: you can still modify the
>>>> variable, but it sends a strong message to the user. Also, it's not
>>>> about deprecation: code base should still rely on these variables.
>>>
>>> so maybe I picked one interpretation over the other.
>>
>> I don't see any contradiction. You can modify a defconst, but the strong
>> message is "you are not supposed to do that". I didn't suggest modifying
>> these variables was expected. Anyway, I acknowledge I wasn't very clear.
>>
>>> Yes, sorry. By "nothing" I mean nothing we cannot achieve with
>>> documentation and a :set method.
>>
>> This will not fix the bug.
>
> Hi Nicolas,
>
> can you remind me what the bug was?  The taskjuggler issue?
>
>
>>
>>> Since we will still rely on the variables, the advantage for
>>> maintenance is something I do not see.
>>
>> As a developer, you have to keep in mind that the string might be
>> changed. Sometimes, it's easy to forget you cannot hardcode it, e.g.
>> when writing a search regexp. I have done a similar mistake in
>> ox-taskjuggler.el, where I expect the effort property to be named
>> ":EFFORT:". More things to remember, more potential bugs, more
>> maintenance efforts.
>>
>>> Cache friendliness I see, but I would think that if someone changes
>>> these variables, they will not keep changing them.
>>
>> Of course. I shouldn't have talked about cache since it makes me sound
>> like a lazy person. I can work around the cache problem.
>>
>> Again my main concern was to move to a proper, Emacs-independent,
>> /minimal/ core syntax, i.e., to define the "Org format". For example, at
>> the moment, external tools cannot rely on "SCHEDULED:" string to write
>> even a basic Org file, because "SCHEDULED:" doesn't clearly belong to
>> the syntax and, therefore, might be incompatible with some
>> configurations.
>
> Yes, as I said, I do see all these problems, but I also feel the responsibility
> to break as few as possible existing configurations.
>
> If you want, I can take a shot at documenting this properly.
>
> - Carsten
>
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>
>

  reply	other threads:[~2013-10-22 18:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-20  8:47 [RFC] Change some defcustoms into defcont Nicolas Goaziou
2013-10-20 18:23 ` Carsten Dominik
2013-10-21  8:56   ` Nicolas Goaziou
2013-10-21 10:26     ` Carsten Dominik
2013-10-21 10:51       ` Nicolas Goaziou
2013-10-21 11:56         ` Carsten Dominik
2013-10-21 15:15           ` Nicolas Goaziou
2013-10-22  7:50             ` Carsten Dominik
2013-10-22  9:52               ` Nicolas Goaziou
2013-10-22 10:34                 ` Carsten Dominik
2013-10-22 18:28                   ` Torsten Wagner [this message]
2013-10-22 20:00                     ` Florian Beck
2013-10-23  8:56                   ` Nicolas Goaziou
2013-10-23 13:25                     ` Carsten Dominik
2013-10-29 14:04                       ` Nicolas Goaziou
2013-10-29 14:11                         ` Nicolas Goaziou
2013-11-16 20:25                       ` Nicolas Goaziou
2013-11-16 23:55                         ` Carsten Dominik
2013-10-21  8:17 ` Sebastien Vauban

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPaq-gMKHD6NyJVfoyMC2hXogD+WGrujK1CRt=+=2-DWpAqNwg@mail.gmail.com' \
    --to=torsten.wagner@gmail.com \
    --cc=drostekirsten@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).