From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Teika Kazura <teika@gmx.com>
Cc: emacs-orgmode@gnu.org, bezjak.miro@gmail.com
Subject: Re: [patch] Bug (regression) in org-replace-disputed-keys. Bisected.
Date: Thu, 13 Nov 2014 23:32:11 +0100 [thread overview]
Message-ID: <874mu2pw9g.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <20141112.204904.450561810143001383.teika@gmx.com> (Teika Kazura's message of "Wed, 12 Nov 2014 20:49:04 +0900 (JST)")
Hello,
Teika Kazura <teika@gmx.com> writes:
> Glad to contribute. I attached two patches, the first for the lisp
> fix,
Thank you. I applied it, with corrections to the commit message. In
particular, you need to add "TINYCHANGE" at its end, unless you sign FSF
papers.
> and the second for org.texi.
Thanks. Some comments follow.
> Now, release notes (http://orgmode.org/Changes.html) fix proposal. I here write "the full version". (Sorry. I know concise is better.)
>
> 1. Version 8.1, "Important bugfixes" section
>
> The following sentence should be moved to "Incompatible changes" section:
> "The replacement of disputed keys is now turned of when reading a date"
>
> Furthermore, the following should be added: "N.B. This is reverted in Version 8.3."
>
> 2. Please add this to the next version "Incompatible changes" section:
> "`org-replace-disputed-keys' has been ignored when reading date since version 8.1, but the former behavior is restored again."
>
> Perhaps to "New features" can be added: "Keybinding for reading date
> can be customized with a new variable
> `org-read-date-minibuffer-local-map'. (In fact, it was introduced in
> version 8.0, but it was not announced.)"
Done, with some tiny change.
> Some comments on my org.texi patch. I renamed the section "Creating
> timestamps" to "Timestamp commands," since not all commands don't
> create. (Links are updated.) I rewrote some explanations. I think it's
> better, but I'm not sure if my tone of voice (e.g. "Date/time prompt
> is ``smart enough''") is acceptable. Some whitespace cleanup
> accompanies, so you may want to use "git show -b".
>
> I added the description of key "!" in timestamp creation. But I don't
> know what "diary" in Emacs is, so you may want to improve it.
> Subject: [PATCH 2/2] org.texi: Timestamp sections.
>
> Section "Creating timestamp" is renamed to "Timestamp commands". `org-read-date-minibuffer-local-map' is described. Other contents improvement in that section.
Please fill your paragraphs.
You need to document what parts are changed.
Also, commit messages, as Texinfo, require sentences to be separated
with two spaces.
> For Org mode to recognize timestamps, they need to be in the specific
> -format. All commands listed below produce timestamps in the correct
> -format.
> +format. All commands listed below automatically fix incomplete
> existing timestamps.
Two spaces.
Also, I don't get the "fix incomplete existing timestamps" part.
> +Many commands prompt for a date. Details for timestamp prompt will be
> explained in a later subsection. (@pxref{The date/time prompt})
Two spaces.
> -Change date at cursor by one day. These key bindings conflict with
> +Change date at cursor by one day. These key bindings conflict with
This change is incorrect.
> @vindex org-read-date-prefer-future
> -When Org mode prompts for a date/time, the default is shown in default
> -date/time format, and the prompt therefore seems to ask for a specific
> -format. But it will in fact accept date/time information in a variety of
> -formats. Generally, the information should start at the beginning of the
> -string. Org mode will find whatever information is in
> -there and derive anything you have not specified from the @emph{default date
> -and time}. The default is usually the current date and time, but when
> +Date/time prompt is ``smart enough'', accepting shorthand notations,
> visual input while viewing the calendar, etc.
I don't think this is better: "smart enough" doesn't explain much.
However, splitting the paragraph in three parts and reordering them
a bit is a good idea.
> @cindex calendar, for selecting date
> @vindex org-popup-calendar-for-date-prompt
> -Parallel to the minibuffer prompt, a calendar is popped up@footnote{If
> -you don't need/want the calendar, configure the variable
> -@code{org-popup-calendar-for-date-prompt}.}. When you exit the date
> -prompt, either by clicking on a date in the calendar, or by pressing
> -@key{RET}, the date selected in the calendar will be combined with the
> -information entered at the prompt. You can control the calendar fully
> -from the minibuffer:
> +Parallel to the minibuffer prompt, a calendar is popped up@footnote{If you
> +don't need/want the calendar, configure the variable
> +@code{org-popup-calendar-for-date-prompt}.}. Calendar-based visual input is
> +possible, too, and it will be combined with the information entered at the
> +prompt. You can control the calendar fully from the minibuffer:
Two spaces (twice).
> +C-. @r{Go to today.}
> +! @r{Show diary entries. @ref{Displaying the Diary, ,
> Displaying the Diary, emacs, The Emacs Editor}}
Two spaces.
> +@vindex org-read-date-minibuffer-local-map
> +S-<cursor> keys conflict with other modes. For the details see
> @xref{Conflicts}. You can fully customize the key binding with the
> variable @code{org-read-date-minibuffer-local-map}.
I don't think it deserves to appear in the manual. Moreover, this has
nothing to do with the calendar. Eventually,
`org-read-date-minibuffer-local-map' is not specifically associated to
binding conflicts.
> @vindex org-read-date-display-live
> -The actions of the date/time prompt may seem complex, but I assure you they
> -will grow on you, and you will start getting annoyed by pretty much any other
> -way of entering a date/time out there. To help you understand what is going
> -on, the current interpretation of your input will be displayed live in the
> -minibuffer@footnote{If you find this distracting, turn the display off with
> -@code{org-read-date-display-live}.}.
> +The interpretation of your input will be shown on-the-fly in the
> +minibuffer. You can turn it off with the variable
> @code{org-read-date-display-live}.
This is more neutral, for sure. I don't mind either way, but, in any
case: two spaces.
> -Filter the agenda view with respect to effort estimates.
> +Filter the agenda view with respect to effort estimates.
?
> -* Copying
> +* Copying
?
> -@multitable {@code{:latex-link-with-unknown-path-format}} {@code{org-latex-link-with-unknown-path-format}}
> +@multitable {@code{:latex-link-with-unknown-path-format}}
> {@code{org-latex-link-with-unknown-path-format}}
?
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-11-13 22:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 11:42 Bug (regression) in org-replace-disputed-keys. Bisected Teika Kazura
2014-09-28 20:07 ` Nicolas Goaziou
2014-10-01 1:22 ` Teika Kazura
2014-11-03 20:54 ` Nicolas Goaziou
2014-11-12 11:49 ` [patch] " Teika Kazura
2014-11-13 22:32 ` Nicolas Goaziou [this message]
2014-11-14 22:29 ` Miro Bezjak
2014-11-18 21:32 ` Nicolas Goaziou
2014-11-19 9:50 ` Miro Bezjak
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=874mu2pw9g.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=bezjak.miro@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=teika@gmx.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).