On Mon, May 20, 2013 at 11:14 AM, Matt Lundin wrote:
> John Hendy writes:
>
>>> On Wed, May 15, 2013 at 2:54 AM, Christian Moe
>>> wrote:
>
>>> I've been following this thread and there has been some great
>>> discussion about future plans for re-write and context-sensitive
>>> functionality. I
John Hendy writes:
>> On Wed, May 15, 2013 at 2:54 AM, Christian Moe wrote:
>> I've been following this thread and there has been some great
>> discussion about future plans for re-write and context-sensitive
>> functionality. In the mean time, can we revert the C-RET behavior back
>> to adding
On Mon, May 20, 2013 at 10:54 AM, John Hendy wrote:
> On Wed, May 15, 2013 at 2:54 AM, Christian Moe wrote:
>>
>> Hi,
>>
>> My user input is partially to blame for this, I think. See toward the
>> end of this thread:
>>
>> http://comments.gmane.org/gmane.emacs.orgmode/69794
>>
>> I was under the
On Wed, May 15, 2013 at 2:54 AM, Christian Moe wrote:
>
> Hi,
>
> My user input is partially to blame for this, I think. See toward the
> end of this thread:
>
> http://comments.gmane.org/gmane.emacs.orgmode/69794
>
> I was under the impression that the behavior of M-RET had changed, but I
> may h
On Fri, May 17, 2013 at 03:26:09PM +0200, Carsten Dominik wrote:
> There was discussion about `C-c *'. For me the main application
> of this command it to turn an item into a headline, and to turn *several*
> lines into a series of headline (by selecting the lines first) - this is
> a very freque
Carsten Dominik writes:
> On 16.5.2013, at 21:11, Jason F. McBrayer wrote:
>> Another thing to take into account in the rewrite is doing the right
>> thing even when electric-indent-mode or electric-layout-mode are
>> enabled. The current implementation is not compatible with
>> electric-indent-
Hi everyone,
yes, thanks for making this table, Samuel.
I think the functionality is a bit overkill, in particular the implementation
with pressing M-RET twice for special functionality. This becomes too
confusing, I think.
The elementary function of M-RET is continue in the current list/outlin
On 16.5.2013, at 21:11, Jason F. McBrayer wrote:
> Bastien writes:
>
>> Thanks a lot Samuel for writing this.
>>
>> Just a quick note to tell you that this discussion *is* important,
>> and well read, as we plan to rewrite those functions. Presenting
>> features wrt contexts so clearly is gr
Bastien writes:
> Thanks a lot Samuel for writing this.
>
> Just a quick note to tell you that this discussion *is* important,
> and well read, as we plan to rewrite those functions. Presenting
> features wrt contexts so clearly is great -- thanks for doing this.
Another thing to take into acco
Eric Abrahamsen writes:
> Samuel Wales writes:
>
>> How about this? IMO this would be ideal.
>>
>> - M-RET is for the current context
>> - C-RET is for a new context
[...]
> I still think it's pretty important to have an option for creating a new
> headline *below* all the contents of the
On 2013-05-15 23:17, Eric Abrahamsen wrote:
Samuel Wales writes:
Also, C-RET and M-RET currently seem to be identical?
I still think it's pretty important to have an option for creating a
new
headline *below* all the contents of the current subtree -- what C-RET
used to do.
Also, the above p
Samuel Wales writes:
> Hi Eric,
>
> On 5/15/13, Eric Abrahamsen wrote:
>> I still think it's pretty important to have an option for creating a new
>> headline *below* all the contents of the current subtree -- what C-RET
>> used to do.
>
> This might be a good thing to make a user preference.
>
Once this gets implemented I'd really like to see the same table in org
manual. It's a really good summary.
Regards,
Miro
On Thu, May 16, 2013 at 8:21 AM, Bastien wrote:
> Samuel Wales writes:
>
> >
> |-+--++--|
> > | command
On Thu, 16 May 2013 09:22:30 +0200
Daniel Bausch wrote:
> Hi!
>
> > I still think it's pretty important to have an option for creating a new
> > headline *below* all the contents of the current subtree -- what C-RET
> > used to do.
>
> I like to second, that there needs to be a short key bindin
Hi!
> I still think it's pretty important to have an option for creating a new
> headline *below* all the contents of the current subtree -- what C-RET
> used to do.
I like to second, that there needs to be a short key binding to insert a
new headline below the current entry when the context is i
Samuel Wales writes:
> |-+--++--|
> | command | context | pos| action |
> |-+--++--|
> | c-ret | any | any|
Hi Eric,
On 5/15/13, Eric Abrahamsen wrote:
> I still think it's pretty important to have an option for creating a new
> headline *below* all the contents of the current subtree -- what C-RET
> used to do.
This might be a good thing to make a user preference.
> Also, the above provides a whole
Samuel Wales writes:
> How about this? IMO this would be ideal.
>
> - M-RET is for the current context
> - C-RET is for a new context
>
> |-+--++--|
> | command | context | pos| action |
>
How about this? IMO this would be ideal.
- M-RET is for the current context
- C-RET is for a new context
|-+--++--|
| command | context | pos| action |
|-+--+---
Christian Moe writes:
> Eric Abrahamsen writes:
>
>> I don't see why `org-ctrl-c-star' --> `org-toggle-heading' isn't enough
>> for creating headlines out of existing text.
>
> Fair point, but I find it useful to have a simpler and speedier
> combination, redundant or not. For instance, I often
Eric Abrahamsen writes:
> I don't see why `org-ctrl-c-star' --> `org-toggle-heading' isn't enough
> for creating headlines out of existing text.
Fair point, but I find it useful to have a simpler and speedier
combination, redundant or not. For instance, I often use Org to make
structured docume
Christian Moe writes:
> Hi,
>
> My user input is partially to blame for this, I think. See toward the
> end of this thread:
>
> http://comments.gmane.org/gmane.emacs.orgmode/69749
>
> I was under the impression that the behavior of M-RET had changed, but I
> may have given a wrong or incomplete d
Hi,
My user input is partially to blame for this, I think. See toward the
end of this thread:
http://comments.gmane.org/gmane.emacs.orgmode/69794
I was under the impression that the behavior of M-RET had changed, but I
may have given a wrong or incomplete description of the "old behavior" I
see
For the past couple of weeks I'm finding that both M-RET and C-RET turn
the line under point into a heading, instead of inserting a new heading
elsewhere. This happens with `org-M-RET-may-split-line' set to anything.
So this:
#+begin_src org
* Chapter One
:PROPERTIES:
:some_prop: t
:END:
In which
Please keep in mind that C-ret is not an ascii or 8-bit character (or
even a character, really), so people using emacs in an xterm (rather
than via X) do not have C-ret available. In general I find that org
mode becomes a little awkward in a terminal due to usage of
ungeneratable characters.
p
Hi Nicolas
Thank you for all the explanations.
On Sun, Dec 4, 2011 at 11:33, Nicolas Goaziou wrote:
> Though, from what I read,
> I think that you really mean to argue for a change of the default value
> of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for
> a change of code.
Hello,
Michael Brand writes:
> I try to argue for some supposed common Org user that likes it simple
> like me, is used to the behavior of M-RET and C-RET on headings and
> is about to learn to use lists and M-RET but doesn't want to know
> about org-M-RET-may-split-line that he prefers to leave
Hi Nicolas
I try to argue for some supposed common Org user that likes it simple
like me, is used to the behavior of M-RET and C-RET on headings and
is about to learn to use lists and M-RET but doesn't want to know
about org-M-RET-may-split-line that he prefers to leave on its default
as typical f
Hello,
Michael Brand writes:
> With
>
> #+begin_src org
> ,*** abc
> ,*** def
> ,- ghi
> ,- jkl
> #+end_src
>
> M-RET on "j" inserts a line above but I expected it below. If I
> want a line above I would move the point to "-" before doing M-RET
> like I do on a heading where I mo
Hi all
Now that I use M-RET more often when editing lists I was about trying
to make a patch to remove what seems to me an inconsistency between
headings and list items. But after I have read the docstrings of
org-insert-item and org-list-insert-item the current behavior seems so
intentional that
You can use M-RET-may-split-line, to make it respect content in lists,
more or less. I would guess the reason that they are different is to be
able to always easily start a new heading.
This is very helpful, thank you. But how to make it so M-RET will:
1. not split line;
2. add new list item
On Fri, 25 Nov 2011 17:49:09 +0100, "sindikat" wrote:
> Hello everyone,
>
> M-RET works with both headings and plainlists, it's DWIM.
> C-RET works only with headings. I wanted to ask, why C-RET is not DWIM?
> Wouldn't users want to add new list item respecting the content?
You can use M-RET-
Hello everyone,
M-RET works with both headings and plainlists, it's DWIM.
C-RET works only with headings. I wanted to ask, why C-RET is not DWIM?
Wouldn't users want to add new list item respecting the content?
Thanks in advance.
33 matches
Mail list logo
