emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Dan Davison <davison@stats.ox.ac.uk>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: keys and command name info
Date: Mon, 09 Aug 2010 14:32:19 -0400	[thread overview]
Message-ID: <878w4f4oy4.fsf@stats.ox.ac.uk> (raw)
In-Reply-To: <20100809101957.GC14007@shi.workgroup> (Gregor Zattler's message of "Mon, 9 Aug 2010 12:19:57 +0200")

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Andreas, org-mode developers,
> * Andreas Burtzlaff <andy13@gmx.net> [09. Aug. 2010]:
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>> I have put a version of the manual as modified by Andreas here:
>>>
>>>    http://orgmode.org/org-manual-with-command-names.pdf
>>>
>>> Not all the command names are in there, but quite a few are.
>>> I'd like to hear from more people
>>>
>>> - if they would like to have the names there (i.e. if it would
>>>   help them finding a command)

I would like the command names in the manual.

- Emacs-lisp has a lovely tradition of naming functions *very*
  descriptively and not being afraid to use long names in the interests
  of accuracy. It's a shame to lose all that by displaying only key
  sequences. It's a linguistic world of its own and I like being exposed
  to it.
- While one can do C-h k, that's not the same as the way one learns the
  function names by skimming the manual

>>> - if the position (first thing in the command description)
>>>   is right, or if it would be better to have it
>>>      - last thing in the description
>>>      - or after the first sentence, this is how the GNUS manual
>>>        does it.

I definitely would want them out on a line of their own with the key
sequence. I liked the right-aligned model.

Or if not right-aligned, is it possible not to have the comma? Maybe a
different font?

Dan

>> 
>> Having the function names in the manual at all makes it look a bit
>> overloaded and might lose us a couple of newbies, I think. Personally, I
>> would not have use for it.
>> 
>> If the names are included in the manual I strongly object to them being
>> at the beginning of the first sentence. The fixed starting column of the
>> sentences becomes variable and that makes it hard to skim through for
>> those who don't want to read the function names.
>
> +1 for the same reasons. 
>
> This is especially true for paragraphs like those:
>
> C-c C-n (outline-next-visible-heading) Next heading.
> C-c C-p (outline-previous-visible-heading) Previous heading.
> C-c C-f (org-forward-same-level) Next heading same level.
> C-c C-b (org-backward-same-level) Previous heading same level.
> C-c C-u (outline-up-heading) Backward to higher level heading.
> C-c C-j (org-goto) Jump to a different place without changing the current outline
>         visibility. Shows the document structure in a temporary buffer, where you can
>         use the following keys to find your destination:
>
>
>> What about having them in the same line as the keybinding but aligned to
>> the right?
>> 
>> `C-c ['                                         org-agenda-file-to-front
>>      Add current file to the list of agenda files.  The file is added to
>>      the front of the list.  If it was already in the list, it is moved
>>      to the front.  With prefix arg, file is added/moved to the end.
>> 
>> It would make the manual longer, but at least it looks clean.
>> It is easy to neglect the function names if one wants, and just as easy
>> to skim through them.
>
> +1 for the same reasons.  
> But Andreas Röhlers original variant is IMHO even better:
>
>>| [ ... ]
>>| `C-c [', org-agenda-file-to-front
>>|     Add current file to the list of agenda files.  The file is added to
>>|     the front of the list.  If it was already in the list, it is moved
>>|     to the front.  With prefix Argument, file is added/moved to the end.

Yes, but let's lose the extra comma.

`C-c [' org-agenda-file-to-front





>
> Here the command name serves as a kind of a heading, it's easy
> to search these locations while at the same time it's easy to
> skim over the pages and not bother with the command names.
>
>
>
> My preference:
>
> 1. as in Andreas Röhlers original ASCII rendering 
> 2. as in Andreas Burtzlaffs ASCII rendering
> 3. not at all
> 4. as in the test manual
>
>
>
> Just me 2¢.  Either way, org-mode is great.  Gregor
>
>
> P.S.: Some of the command names don't help that much:
>
> C-c C-c (org-ctrl-c-ctrl-c) If there is a checkbox (see Section 5.6 [Checkboxes],
>         page 46) in the item line, toggle the state of the checkbox. If not, this command
>         makes sure that all the items on this list level use the same bullet. Furthermore,
>         if this is an ordered list, make sure the numbering is OK.
> C-c -   (org-ctrl-c-minus) Cycle the entire list level through the different item-
>         ize/enumerate bullets (`-', `+', `*', `1.', `1)'). With a numeric prefix argument
>         N, select the Nth bullet from this list. If there is an active region when calling
>         this, all lines will be converted to list items. If the first line already was a list
>         item, any item markers will be removed from the list. Finally, even without an
>         active region, a normal line will be converted into a list item.
> C-c *   (org-ctrl-c-star) Turn a plain list item into a headline (so that it becomes
>         a subheading at its location). See Section 2.5 [Structure editing], page 7, for a
>         detailed explanation.
>
> But even this gives a clue in how it all works.
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

  parent reply	other threads:[~2010-08-09 18:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28 19:36 keys and command name info Andreas Röhler
2010-07-29  6:45 ` Tassilo Horn
2010-07-29 13:47   ` Andreas Röhler
2010-07-29 15:19     ` Andreas Röhler
2010-07-29 18:08       ` Tassilo Horn
2010-07-30  9:40         ` Andreas Röhler
2010-08-07 19:39           ` Carsten Dominik
2010-08-08 13:57             ` Andreas Röhler
2010-07-31  8:53     ` Bastien
2010-07-31 17:53       ` Andreas Röhler
2010-07-31 19:02         ` Thomas S. Dye
2010-08-01  9:42         ` Bastien
2010-08-01 16:40           ` Andreas Röhler
2010-08-02  6:32 ` Carsten Dominik
2010-08-08 22:26   ` Gregor Zattler
2010-08-09  6:43     ` Carsten Dominik
2010-08-09  9:37       ` Andreas Burtzlaff
2010-08-09 10:19         ` Gregor Zattler
2010-08-09 10:31           ` Carsten Dominik
2010-08-09 18:32           ` Dan Davison [this message]
2010-08-09 19:28             ` Dan Davison
2010-08-11 10:05               ` Carsten Dominik
2010-08-11 10:23                 ` Andreas Röhler
2010-08-11 10:27                   ` Carsten Dominik
2010-08-13 13:45                 ` Andreas Röhler
2010-08-13 14:20                   ` Dan Davison
2010-08-13 19:30                 ` Andreas Röhler
2010-08-15  7:37                   ` Carsten Dominik
2010-08-15  7:39                     ` Carsten Dominik
2010-08-15 19:07                       ` Andreas Röhler
2010-08-16  8:57                         ` Carsten Dominik
2010-08-17 12:43                           ` Andreas Röhler
2010-08-18  8:38                             ` Carsten Dominik
2010-08-20  6:27                               ` Andreas Röhler
2010-08-20  7:31                                 ` Carsten Dominik
2010-08-20  8:13                                   ` Andreas Röhler
2010-08-20  7:44                                 ` Carsten Dominik
2010-08-17 15:44                           ` Andreas Röhler
2010-08-10  1:28             ` Memnon Anon
2010-08-09 14:23       ` Nick Dokos
2010-08-10  7:48       ` OT: smex.el (was Re: keys and command name info) Austin Frank
2010-08-20 11:20 ` keys and command name info Carsten Dominik
2010-08-20 11:32   ` Stefan Vollmar
2010-08-20 13:23   ` Bernt Hansen

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=878w4f4oy4.fsf@stats.ox.ac.uk \
    --to=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /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).