add link to the manual's source

[parkour-doc.git] / TODO

add textobjects for head, tail, and body, working from anywhere in the list.
the one for body should encompass all sexps after the last_distinguished argument.

add textobject for ]e, but just redefine aw to take count and to use it to skip words

"far" objectwise paste - after the current _list_?
gp and gP?

push expand region semantic ranges on a stack, so they can be shrunk later.
lateral semantic motions could be recorded as well?
shrink with gv or V?

yyp/ddp a line comment pastes it after the whole series of comments
inside a list is even weirder. I guess the paste is wrong, not the yank/delete

vis-only: dot-repeating a daw accumulates the words in the register, instead of overwriting.

db on ) and paste is not objectwise.
it IS whole_object, and splice-killing.

copying "asdf) (qwer" will return asdfqwer - concatenated.

M-C-e jumps backwards when at the beginning of a line comment block
it also crashes when on a comment right at EOF

in TA/howl replace ctrl+alt+left/up for splice-killing with something that
does not involve arrows. use the ctrl+alt+left/right for the floating motions.

Make delete hungry even in between sexps on the same line
(now it works at indentation and before closing paren)

Enter inside an atom before a margin comment doesn't split the atom.

vis-only: adopt some things from symex:
instead of gT for transpose-sexps, use move/shift left and right (H and L in symex.)

vis-only: make emacs mark work for all selections

why escaped_at() in the very first line comment returned nil?

; at top level before a one-line sexp doesn't comment it out.

; _right_ after a line comment opens a margin comment. should open a same-level comment

move the prefix^1 from the parser into the dialect-specific configs.
some prefixes can concatenate, but for others it doesn't make sense,
or it does only for some combinations.

reconfigure the parser - newLISP has even weirder rules than picolisp - the multi esc is [square brackets],
there is overlap for line comments and block comments - # and #{} (parsing it is fine, but input cannot be smart)
the current heuristics for deciding what delimiter is list and what is not will be wrong.
explicit separation is necessary.
An extra dict with the opening delims of string/multiesc AS KEYS.
This way it will be impossible to list two delims for different roles. (If you do, it will be obvious mistake)
local roles = {['"'] = "string", [';'] = "comment", ['#|'] = "comment"}
local roles = {['"'] = "string", ['{'] = "string", ['[text]'] = "string",
                ['['] = "multiesc", [';'] = "comment", ['#'] = "comment"}  -- newlisp
or, better:
delimiters = {
['('] = ')'
['"'] = {['"'], string = true},
['#|'] = {['|#'], comment = true}}

see if symbol\ with\ spaces is supposed to be a single symbol in some dialects

) when at top-level, to call repl_send? (like in lisp machines and Medley)
(but my mode is hybrid, what to do when an actual enter is pressed.
or, if we autoinsert enter after a ), what if there was already an
empty line there?)

FIXME: add nline to delimited_range and nested_pair

when autopairing a new () right after the last distinguished arg, automatically
wrap on a new line. (like in Medley)

see if the Cp() * Cc(offset) / incr could be simplified to Cp() and do
the incr on access of .start/.finish with a metatable?
seems like the incr place is a hotspot. but the perf says it's a C func,
so maybe it's just Cp() and is unavoidable.

use 'bisect' insertion instead of the current rewind + cut off.
the sexps past the current one will have to be traversed and have .start/.finish corrected.
Is this going to be slow?

backslash:
 - take care of backslash-escaped chars in " and | blocks (what about comments?).
   no need to delete the backslash along with the char in \a, only if they are exactly before a closing doublequote
   no need to ask Character to escape:, just make sure it's not exactly before a delimiter, and it's not missing a leading #,
   when in code.
 - remove the whole #\a when deleting any of the three chars? (because it might be #\\)
 - define the character literal per language:
   Clojure \h, \uNNNN, \backspace \formfeed \newline \return \space \tab
   Scheme #\h, #\xNN, \alarm \backspace \delete \escape \newline \null \return \space \tab
   Lisp ?
   why, though? for correct space-delimiting during fmt; for safe deletion;

change pick_out to preserve not only ") (" space but "^    (" too
otherwise M-d destroys the space separators and indentation
OR, preserve "atom (" and ") atom" too.
OR, remove even the ") (" and just call refmt when #skips > 0

not all struct operators make sense through pick_out; some work on the innermost sexp that surrounds the selection.
wrap/doublequote work, but is this useful; should I change the definition

see why trailing_space in refmt_list DOESN'T modify adj.

^L
;;; comments cause wrong count of sexps
and the stored sexp_path can't be fullfilled
separating the ^L fixes the issue

motions inside the very last defun always trigger reparses with advance of -1
check where in the code this could happen. probably the [#parent + 1] trick (see below)

find a less wasteful way to detect EOF than the parent[#parent + 1] autovivification trick,
which reparses the next defun one or more times.

in input:insert_pair(), (and everywhere), when the cursor is right after a ;;;; comment
_, parent = sexp_at() (and sexp_path) return THE COMMENT, not nil, root, or {}
this is consistent, like with sexp| but is confusing. is is useful to keep it?
no, it's not consistent - not if the PARENT is the comment

instead of node, parent = sexp_at(), which is just a special case,
use sexp_path everywhere. The full crumbtrail it returns gives more opportunities.
put the n index of each sexp into its node in the parse tree.

when i delete stuff in a list, and this list is at operand position in its parent,
the parent should reindent, but doesn't. The problem is that, when I'm insert mode,
I don't wan't to refmt the current list, it will wipe all the spaces.
But the problem occurs even in normal mode. I could fix at least that?
but this means that refmt should _always_ creep up to top level. which I avoid deliberately.

refmt:
 + several = are needed to fully refmt certain lists - inserting/pasting a multiline between two multilines.
   or joining a multiline before another multiline (like in let).  !!! !!! !!!
 + raising multiline lists ends up with a wrong indent, sometimes (in a let) (Check if it is the same issue as above)
 - _multiline_ strings/block-comments mess up the indent after them, if the next sexp is on the same line as the string
   the column of the closing delimiter is calculated as if the string was one-liner. Using bol_at wold work, but vis
   doesn't have one that works for arbitrary offsets.
 - M-q on an empty line puts the cursor like C-a. could be either as Del or Backspace (next or prev sexp)
   (currently it seems like it works as after_finish should)

Tabs mess up indenting; the indent code counts each char as width=1, but tabs are longer.

add .lines property to quasilists during parsing.
this way i can know how many lines are in a list or multiline string or block comment
and fix some of the problems with fmt

clojure: defn squarewords - it supports doc-string? attr-map? before the [params*]

the table values I used with squarewords might be necessary for indent too.
in clojure-mode they call it backtracking indent, it is a list instead of a scalar number
maybe use the pattern-matching that I planned to replace sexp_at for the indent expressions as well.
(if suitable, though)

add a new function - reindent_defun_kr: (or _otbs)
to put each closing paren on a line of its own.
And make it possible to toggle between the two styles.

make paragraph motions while in a group of line comments move to the beginning/end of _the group_
(instead of doing what backward-up/forward-up already do)

for fmt, consider using patterns for configuration, like cl-indentify

Objectwise deletion happens even without textobjects being explicitly used. Instead, the condition is whether a word/sexp
disappears as result of the deletion. With lists, this is a feature, you don't normally want lingering
spaces. But in strings/comments, where there are no particular rules about whitespace, this can be considered a bug.

reset cursor position to the beginning of the sexp/list on splice, raise, splice-killing?
some other paredits do that (it varies, though).
this would "fix" the annoyance where the cursor jumps to the next sexp after splice-killing.
it was deliberate (to not leave the cursor in whitespace, mostly to tame autoselect), and is okay when deleting,
but is annoying when splice-killing.

Racket has here strings. add them to the parser
#<<EOF

EOF

asd|f qwer
de:
asd|
should be:
asd| qwer

(asdf
|  as)
D doesn't gather the closing paren to the prev line. If the cursor was exactly |asdf, then it does gather the paren.

M-d crashes in ;;; comment with only spaces inside, in all editors
the cursor must be right after ";;; ". if further in, it is not reproducible.
the difference comes from pick_out - ndeleted is 0 when crashing, and higher when not
but the cursor position is weird when not crashing.

x-ing the |# of a block comment lands the cursor one char too far