emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
To: emacs-orgmode@gnu.org
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>
Subject: Re: [New exporter] Key bindings and typographical error
Date: Fri, 8 Feb 2013 15:52:13 +0100	[thread overview]
Message-ID: <20130208145213.GF23289@kuru.dyndns-at-home.com> (raw)
In-Reply-To: <874nhm6h75.fsf@ucl.ac.uk>

Hi Eric and Seb,

On Sat, Feb 09, 2013 at 12:28:06AM +1030, Eric S Fraga wrote:
> 
> Given that we have moved to a multi-key sequence for selecting exporter
> and then action, could these two aspects not be dealt with in the
> mini-buffer?  I find the display of all the options confusing...  I
> would rather have the dispatcher prompt, in the mini-buffer, something
> along the lines of:
> 
> : Export to: (l) latex, (h) html, (o) ODT, (a) ascii
> 
> with the choices obviously depending on the backends initialised.  Then,
> depending on the key (e.g. l):
> 
> : Export as: (l) file, (b) buffer, (p) PDF, ...
> 

Here one of the options (file?) could be the default, so it would be
sufficient to hit RET for most cases.

> Just a thought which arises from my having to use small screens
> sometimes as I'm a sucker for punishment and insist on using Emacs on my
> phone and the dispatch window is too large sometimes...
> 

I agree whole-heartedly.  The dispatcher menu has always bugged me.  It
doesn't seem to fit into rest of Emacs' minibuffer oriented interface.
For me this would mean one more step towards making Org mode friendlier
to text terminals.

> I would also suggest that beamer be a different target, separate from
> latex, chosen by a different first key (e.g. b).  This would then allow
> some unification of the second key sequence (f=file, b=buffer, p=PDF,
> v=view...)?
> 

I am ambivalent about this suggestion.

> Finally, I could be more radical and suggest that the whole export
> dispatch should be based on keymaps... with C-h, as usual, bringing up
> the options.  But this might be too radical ;-)
> 

Again, agree whole-heartedly.  :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

next prev parent reply	other threads:[~2013-02-08 14:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 17:01 [New exporter] Key bindings and typographical error Sebastien Vauban
2013-02-08 13:58 ` Eric S Fraga
2013-02-08 14:52   ` Suvayu Ali [this message]
2013-02-08 16:52     ` Charles Berry
2013-02-08 23:33       ` Eric S Fraga
2013-02-08 16:42   ` Sebastien Vauban
2013-02-08 23:35     ` Eric S Fraga
2013-02-08 23:38     ` Robert Eckl
2013-02-08 21:27 ` Nicolas Goaziou

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=20130208145213.GF23289@kuru.dyndns-at-home.com \
    --to=fatkasuvayu+linux@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=wxhgmqzgwmuf@spammotel.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

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).