TODO.org

Scheduled

Submatcher reorganization

• State “TODO” from [2018-12-10 Mon 03:38]

API design should follow consistent criteria.

Comments

• State “TODO” from [2018-12-10 Mon 03:38]

Bugs

Known reader macros so far

• State “TODO” from [2018-11-21 Wed 01:42]
• #\char
• #H() from cl21
• #!?[-+]sym
• #(1 2 3)
• #2A((1) (2))
• #123#
• #| |#
• #.(foo)

replace-regex-in-string ideas [5/5]

• State “TODO” from [2018-11-21 Wed 01:42]
• [X] “#\” -> ” ?”, a half assed char conversion
• [X] “#[^ (]+(” -> “(“, for cl21 hash
• [X] “#p"” -> “"”, pathname
• [X] “#\+” -> ” ”
• [X] “#|foo|#” -> ”* *”

pospcase–buffer-substring can’t read “#\\”

• State “TODO” from [2018-12-05 Wed 03:50]

unreliable forward-sexp

• State “TODO” from [2018-12-21 Fri 14:07]

Known problematic cases:

• #2A((1) (2))
• #.(foo)

Do they break nth-chop-off?

Reorder keywords for parameter-group

• State “TODO” from [2018-12-23 Sun 14:45]
• To properly highlight the following declaration:

  (defun foo (&key (quote #'bar) (function ’baz)))
      

  The keywords order should be:

  1. #'baz and &key, by non-pospcase keywords
  2. parameter-group, (including masked and ignored heading-keyword &key)
  3. quote and function, lisp keywords that can be both macro and symbol

fontspecs feels inconsistent

• State “TODO” from [2018-12-24 Mon 10:35]

Actually, current design makes sense too.

• If submatcher is specified with cons cell:

  (name . submatcher)

  Without submatcher:

  name

  not

  (name) or (name . nil)

  Maybe optionally allow this notation?

• And faces are specified with list:

  (font-lock-variable-name-face font-lock-type-face)

  and requires parenthesis even when single element:

  (font-lock-variable-name-face)

  Because some faces are decided dynamically like:

  ((pospcase-font-lock-variable-face-form (match 1)))

  So mandatory parenthesis makes sense.

defmethod *feature* idiom

• State “TODO” from [2019-01-13 Sun 02:44]

(defmethod #+foo-1.0 old-func
           #+foo-2.0 new-func
  :before
  ((bar baz) (qux quux))
  body)

Supporting this idiom is very difficult for multiple reasons:

1. #+foo sexp is invalid in elisp, so elispify hack is involved.
2. Number of feature cases are arbitrary.

So, very involved extension to both pospcase-read and pcase are required.

Even worse, what if a user want to pattern match against #+foo? In that case some kind of global toggle switch is needed too.

unhighlighted bar in (loop with foo and bar)

• State “TODO” from [2019-06-30 Sun 08:11]

Features

Use as much pcase as possible

• State “TODO” from [2018-11-19 Mon 12:27]

elispification

• State “TODO” from [2018-11-19 Mon 13:34]

submatcher generator

• Something like:

  (pospcase-font-lock ’lisp-mode
                       '(`(defun ,name ,args))
                       '((name . font-lock-function-name-face)
                         ((args . (`(,arg ,type)
                                   `,arg)))
                         ((arg . font-lock-function-name-face)
                          (type . font-lock-type-face))))
      

  and it calls

  (goto-char (car args))
  (pospcase-font-lock-submatcher (`(,arg ,type)
                                  `,arg))
      

define pospcase--after-open-paren

• State “TODO” from [2018-11-23 Fri 11:11]

  (let ((limit (point-max))
        (keyword "defun"))
    (when (search-forward keyword limit t)
      (let ((kw-begin (match-beginning 0))
            (kw-end (match-end 0))
            begin end)
        (and
         (looking-at "[ \t\n;]")
         (setq end (match-end 0))
         (search-backward "(" nil t)
         (setq begin (match-beginning 0))
         (progn
           (goto-char (match-end 0))
           (forward-comment most-positive-fixnum)
           (= (point) kw-begin))
         (set-match-data (list begin end
                               kw-begin kw-end)))))
    (match-string 1))
  
  ;;; bar
  (
  ;;; foo
  defun foo (bar) baz)
      

Primary matcher should use pcase too?

• State “TODO” from [2018-11-23 Fri 14:13]
• Example: `((or labels cl-labels) ,name ,args . ,__)

Should I make pospcase-let?

• State “TODO” from [2018-12-04 Tue 11:07]

What to do with case insensitivity?

• State “TODO” from [2018-12-20 Thu 14:12]

ignore-errors should be togglable

• State “TODO” from [2018-12-23 Sun 14:50]

unlocking heading-keyword restriction?

• State “TODO” from [2019-01-11 Fri 05:29]

I can’t think any use case, but heading-keyword requirement can be lifted by searching the first quoted symbol in the pattern:

`(,name ,(and 'bizarre-syntax-keyword heading-keyword) ,args . ,_)

or the first non-comma symbol:

`(,name bizarre-syntax-keyword ,args . ,_)

Documentation

should I mention the difference between pospcase-read and read-symbol-positions-list ?

• State “NOTE” from [2018-12-02 Sun 04:10]

(let ((read-with-symbol-positions t))
  (read "(foo (foo))")
  read-symbol-positions-list)

Design guideline

errors

• State “NOTE” from [2018-11-22 Thu 10:32]
• Generic functions like pospcase, pospcase-at, pospcase-read shouldn’t silently discard errors like scan-error for unmatched parenthesis, invalid-read-syntax for unparsable buffer segment even after elispification.
• Externally exposed font-lock functions (submatchers, preform, postform, etc.) and macros should discard errors silently.
• How about internal font-lock functions (iterator, etc)?

use idioms

• State “TODO” from [2018-11-29 Thu 11:24]
• use push

  (cl-loop with result do (setq result (append result (walk))))
      

  should be

  (cl-loop with result do (push (walk) result))
      

read-from-string should be major-mode aware? In case someone use (pred vectorp) in emacs-lisp-mode?

• State “TODO” from [2018-11-30 Fri 09:37]

down-list is major-mode aware. Does elispify cause inconsistency?

• State “TODO” from [2018-11-30 Fri 09:43]

consistent arity-like submatcher naming convention

• State “TODO” from [2018-12-04 Tue 17:16]

prematches should be highlighted even submatchers return nil?

• State “TODO” from [2018-12-27 Thu 18:51]

(setf (foo bar) baz)

Should the keyword setf be highlighted here?