Greg Minshall <minsh...@umich.edu> writes:
> i wonder if a grid might help? i.e., contexts in which we are all > happy, others where we might disagree? below, i try; i'm sure i've > missed cases. > > question: what does <RET> do/would we like it to do when we are in? > > ========================================= > tables: next row, current column > > Org Src buffers: electric-indent per declared language major > mode rules. > > src blocks: same as in Org Src buffers (i think there have been some > very nice "recent" improvements here, which are great, and for which, > belated thanks!) > > ^^ i think we are all happy with those > ========================================= > ========================================= > vv here, i think, well, "Houston, ..." :) > > after n* heading: > column 1 > vs > column n+2 > > list entry (end of line): > column where previous "-" was (to start a new list item) > vs > two columns *after* where previous "-" was (to continue with the > current list item) > > immediately after (non-blank, non-list, non-heading) with text starting > in column n: > column 1 > vs > column n > > immediately after a blank line: > column 1 > vs > column of first non-blank character of most recent non-blank line? > ========================================= > > surveymonkey, anyone? :) not to vote, but i'm curious to what extent > we divide cleanly into two groups (in which case, maybe an option for > which "major mode indentation" style one prefers for org-mode makes > sense), or if we are uniformly distributed across the power set. :) > > btw, it seems to me that M-q (fill-paragraph) also has *something* to > say here. i.e., though *i* want <RET> from a list entry to line me up > at the previous "-", i want M-q within a list entry to add new lines > starting two columns past that point. i guess i see it as orthogonal > (and, so far, non-controversial) to the current discussion, and hope it > so stays! > > cheers, Greg Hi Greg, I think there are more than two groups. I would start by considering it as two top level groups 1. Indentation behaviour with electric-indent enabled and org-adapt-indent set to t (the current defaults) 2. Indentation behaviour with electric-indent disabled as suggested in the org NEWS file. 3. Indentation behaviour with different values for org-adaptive-indentation. Then we have the different values which org-adapt-indentation can be set to that will 'tweak' the way adaptive indentation works in different contexts. It is my guess that the majority of people can in fact have the behaviour they want either by turning of electric indent mode or by setting org-adaptive-indentation to one of the supported values. I would encourage anyone who is not happy with the default to look at the different supported values for org-adaptive-indentation to see if the tweaking it provides might make org indentation work closer to what they like (as opposed to turning all automatic indentation off). There are probably a few edge cases, but to identify those, we need to first eliminate all the cases which can be 'resolved' with existing configuration options. Tim -- Tim Cross
