Re: [O] M-RET vs C-RET

2014-11-27 Thread Andreas Leha
Hi,

[ ... ]



 Here's another of my pet-griefs
 - a
 - b

 | → M-RET will give me an itme 
 | → M-RET will give me a headline

 Why is the behavior a function of amount of whitespace/newlines to
 nearest element?  This makes not sense to me and goes against what I
 want, namely act in accordance to element at point. . .

 Blank lines belong to the element at point above.

 In particular, number of blank lines is meaningful in plain lists and
 footnote definitions (2 blank lines mark the end of the element). In
 the first line, you're still in the list, in the next one, you're not
 anymore, hence the behaviour.

 Think about

   - a

   - b

 /I/ know why it does what it does.  But how about the guy who's been
 using Org for five minutes?  Even knowing the technical/syntax reason, I
 do not find this to be predictable, and meaningful—especially in my
 initial example, less so when separating items by two lines.

Just to add to that side thread:

I too fall regularly into that and have to undo, add more newlines and hit
M-RET again.  I have been using orgmode for quite some time and still
this is not 'predictable' for me.

Regards,
Andreas




Re: [O] M-RET vs C-RET

2014-11-26 Thread Nicolas Goaziou
Rasmus ras...@gmx.us writes:

 I don't have a grand vision, but, ideally, I'd want M-RET to do the
 right thing, which is my book is often create an element similar to
 element at point, and is certainly not but my #+begin_src emacs-lisp
 code on a headline.  I agree the logical action is to the eye of the
 beholder.  To me, some elements have a very clear-cut next logical
 thing (item, headline, white space (headline), some keywords, maybe
 tables), others don't (e.g. src-blocks and export blocks.).  IMO, we can
 disable most of element-actions (literately keywords and tables) out of
 the box, much like e.g. `scroll-left'.

It would be nice to have complete specifications of do the right
thing.

Also, it is important to have a way to insert a headline whatever is
around, and one to insert a headline at the end of the current section
or even great-parent.

Currently C-RET is sub-optimal since it is equivalent to C-u M-RET. It
might be possible to re-define both M-RET and C-RET so they can cover
all use-cases in a predictable, and meaningful, fashion.

 Here's another of my pet-griefs
 - a
 - b

 | → M-RET will give me an itme 
 | → M-RET will give me a headline

 Why is the behavior a function of amount of whitespace/newlines to
 nearest element?  This makes not sense to me and goes against what I
 want, namely act in accordance to element at point. . .

Blank lines belong to the element at point above.

In particular, number of blank lines is meaningful in plain lists and
footnote definitions (2 blank lines mark the end of the element). In the
first line, you're still in the list, in the next one, you're not
anymore, hence the behaviour.

Think about

  - a

  - b

  |


Regards,



Re: [O] M-RET vs C-RET

2014-11-26 Thread Rasmus
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 I don't have a grand vision, but, ideally, I'd want M-RET to do the
 right thing, which is my book is often create an element similar to
 element at point, and is certainly not but my #+begin_src emacs-lisp
 code on a headline.  I agree the logical action is to the eye of the
 beholder.  To me, some elements have a very clear-cut next logical
 thing (item, headline, white space (headline), some keywords, maybe
 tables), others don't (e.g. src-blocks and export blocks.).  IMO, we can
 disable most of element-actions (literately keywords and tables) out of
 the box, much like e.g. `scroll-left'.

 It would be nice to have complete specifications of do the right
 thing.

I agree.

Some quick thoughts:

babel-call → maybe insert new call line?
comment → new commented line?
Drawer, property-drawer → insert new drawer template?
fixed-width → clone :
headline → `org-insert-headline'
inlinetask → insert new inlinetask? 
item → `org-insert-headline'
keyword → `org-insert-keyword' but doesn't cover all keywords...
paragraph → `org-insert-headline'
plain-list → `org-insert-headline'
table-row → what it does now

No clue:

center-block → 
clock →
comment-block → 
diary-sexp →
dynamic-block → 
example-block → 
export-block → 
horizontal-rule →
latex-environment →
node-property →
planning → 
quote-block → 
special-block →
src-block →
table →
verse-block → 

I agree that if there exited a list of rights things to do, and it was
implemented, it may not be optimal to put it on M-RET [I'm not
sure]. . .

 Also, it is important to have a way to insert a headline whatever is
 around, and one to insert a headline at the end of the current section
 or even great-parent.

For the two latter: I only learned about the current possibility of
doing this reading the docstring of `org-insert-headline'.  I haven't
used it, and I don't think it's immediately helpful to me, but who
knows.

 Currently C-RET is sub-optimal since it is equivalent to C-u M-RET. It
 might be possible to re-define both M-RET and C-RET so they can cover
 all use-cases in a predictable, and meaningful, fashion.

Would be cool.

 Here's another of my pet-griefs
 - a
 - b

 | → M-RET will give me an itme 
 | → M-RET will give me a headline

 Why is the behavior a function of amount of whitespace/newlines to
 nearest element?  This makes not sense to me and goes against what I
 want, namely act in accordance to element at point. . .

 Blank lines belong to the element at point above.

 In particular, number of blank lines is meaningful in plain lists and
 footnote definitions (2 blank lines mark the end of the element). In
 the first line, you're still in the list, in the next one, you're not
 anymore, hence the behaviour.

 Think about

   - a

   - b

/I/ know why it does what it does.  But how about the guy who's been
using Org for five minutes?  Even knowing the technical/syntax reason, I
do not find this to be predictable, and meaningful—especially in my
initial example, less so when separating items by two lines.

Cheers,
Rasmus

-- 
Don't panic!!!








Re: [O] M-RET vs C-RET

2014-11-25 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 In a similar vein to this thread, I've always wondered if the following
 is normal or not.

 Having such a file:

 ** TODO Research

 - Who are the competitors?
 - What are our product's advantages?
 - Target market
 - Elevator pitch|

 Check out with Laura...

 Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
 tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
 quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
 consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
 cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
 proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

 ** TODO Define priorities

 If I want to cut the task into 2 at the point of the cursor (vertical
 bar, after pitch), I thought doing M-RET or C-RET were the way to go.

 But:

 - M-RET inserts a new item in the list
 - C-RET inserts a new headline... but after the Lorem paragraph.

One used to be able to type C-u M-RET and get a headline in the middle
of the list, but this was changed in
6c9b3ad91f6d3758471d194b75cbbf7a1030e18b.


Regards,

-- 
Nicolas Goaziou




Re: [O] M-RET vs C-RET

2014-11-25 Thread Rasmus
Hi,

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 From my point of view, we can make every function tied to M-RET beyond
 `org-insert-headline' configurable and turned off by default.  This may,
 however, also add confusion (why did M-RET work in X's Org but not in
 mine...).

 In this case, S-RET is a superior (as in less confusing) choice.

I see.  That's probably OK.

 Anyway, I assume M-RET on keywords is just a first step. So, what's the
 big picture? I think it would help to know the complete specifications
 of the M-RET you envision, as it could make more sense than the sum of
 its parts.

You're the architect.  I just submit an occasional patch or bug-fix
(under much guidance).

I don't have a grand vision, but, ideally, I'd want M-RET to do the
right thing, which is my book is often create an element similar to
element at point, and is certainly not but my #+begin_src emacs-lisp
code on a headline.  I agree the logical action is to the eye of the
beholder.  To me, some elements have a very clear-cut next logical
thing (item, headline, white space (headline), some keywords, maybe
tables), others don't (e.g. src-blocks and export blocks.).  IMO, we can
disable most of element-actions (literately keywords and tables) out of
the box, much like e.g. `scroll-left'.

Sebastien Vauban sva-n...@mygooglest.com
writes:

 Having such a file:

 ** TODO Research
 - [...]
 - Elevator pitch|

 Check out with Laura...

 Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
 [...]
 
 If I want to cut the task into 2 at the point of the cursor (vertical
 bar, after pitch), I thought doing M-RET or C-RET were the way to go.

Here's another of my pet-griefs


- a
- b

| → M-RET will give me an itme 
| → M-RET will give me a headline

Why is the behavior a function of amount of whitespace/newlines to
nearest element?  This makes not sense to me and goes against what I
want, namely act in accordance to element at point. . .

—Rasmus

-- 
Need more coffee. . .