profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/noctuid/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Fox Kiester noctuid Atlanta, GA I am a program writing program-writing programs.

noctuid/evil-guide 914

Draft of a guide for using emacs with evil

noctuid/general.el 682

More convenient key definitions in emacs

noctuid/dotfiles 352

Mouseless Workflow (WIP)

noctuid/link-hint.el 104

Pentadactyl-like Link Hinting in Emacs with Avy

noctuid/evil-textobj-anyblock 29

Expanded Port of the Vim textobj-anyblock Plugin (to be deprecated in favor of targets.el)

noctuid/emacs-sentence-navigation 23

(Broken) Better Sentence Movement Commands and Evil Text Objects

noctuid/framegroups.el 22

Workspaces for emacs using frames

noctuid/annalist.el 18

Record and display information such as keybindings

noctuid/evil-textobj-column 13

Column Text Objects for Evil

noctuid/chronicler.el 5

Track and Analyze Writing Statistics for Org Files in Emacs

issue commentnoctuid/link-hint.el

Add link navigation and maybe even Org todo cycling

#39 should at least be partially implemented to make this easier to do (e.g. link-hint-define-action to add default implementation).

PhilHudson

comment created time in 6 days

pull request commentnoctuid/link-hint.el

(feature): support orglink-mode

Thanks! Any reason you know to prefer it over org-link-minor-mode? There doesn't seem a comparison in the documentation.

mohkale

comment created time in 15 days

push eventnoctuid/link-hint.el

Mohsin Kaleem

commit sha 83cd0489b16f013647d0507ef20905a0a91db433

(feature): support orglink-mode

view details

push time in 15 days

PR merged noctuid/link-hint.el

(feature): support orglink-mode

An alternative org-link-minor-mode maintained by tarsius.

+1 -1

0 comment

1 changed file

mohkale

pr closed time in 15 days

pull request commentnoctuid/general.el

Allow :general use-package to be given multiple times

Great, thanks!

mohkale

comment created time in 15 days

push eventnoctuid/general.el

Mohsin Kaleem

commit sha 26f1d4c4e258c40e6b70ce831a04800c914f29b3

Allow :general use-package to be given multiple times Closes #446

view details

push time in 15 days

issue closednoctuid/general.el

Allow multiple use-package declarations

So I didn't know this beforehand but evidently you can have multiple, same, configuration sections in use-package block and it'll all be expanded in the expected order. For example, this is perfectly valid.

(use-package foo
  :init
  (message "init1")

  :init
  (message "init2"))

But for some reason general.el only accepts the first :general section and any subsequent copies are just ignored.

(use-package foo
  :init
  (defun foo () (message "init1"))
  :general
  ("C-c f" 'foo)

  :init
  (defun bar () (message "init2"))
  :general
  ("C-c b" 'bar))

If you macroexpand this declaration then you'll notice only the "C-c f" binding is setup and the other one is descarded. I'd like general.el to not do this.

closed time in 15 days

mohkale

issue commentminad/consult

Using 'n' or 'N' to move between searched string after consult-line

Keep in mind that will only work if you never use anything but consult-line for searching though. It also won't correctly support using n as a motion with an operator.

akagr

comment created time in 23 days

issue commentnoctuid/general.el

Release on melpa-stable

I thought there was already a dedicated issue, but apparently there wasn't. See #497.

4lex1v

comment created time in 25 days

issue openednoctuid/general.el

Rewrite

I wrote a PoC a while ago with some minimal functionality (keymap/state aliases, :prefix handling, prefix map creation, auto kbd, etc.). Once I've written tests and cleaned it up, I will create a branch for it. There is no timeline for this to become stable and replace general.el. This is not a priority for me since general.el works, and I don't think there's a huge interest in this, so it might be many years before that happens.

Summary of changes/tl;dr

  • cleaner internal implementation and extension system
  • more powerful extension system (internals implemented pretty much entirely through extension system)
  • performance gotchas addressed
  • better documentation
  • leto.el - macro to expand to definer statements to minimal, human-readable code (for transparency to show what a definer actually does)
  • more alternate definition syntaxes
  • single definer recommended for most situations that doesn't have the caveats of general-def; short name (just the new package name)
  • more non-keybinding configuration helpers (in separate file)

Why rewrite?

  • Simpler implementation. General was not so general in the beginning and has special handling for a lot of functionality (especially evil support being hardcoded as opposed to implemented using the extension system). The general.el internals should be generic too.
    • Almost all functionality in the rewrite will be implemented as a linear sequence of transformations over keyword arguments and then keybindings.
    • The extension system will be the same as the internal implementation. The only difference will be that helpers will be provided to insert keyword argument and keybinding parsers in the correct order in a forwards-compatible way (since parsers can transform/add new keybindings or generate metadata, order will matter)
    • Transformations can alter keyword arguments (e.g. to expand keymap aliases) and keybindings (e.g. to apply kbd to the key). They can add new keybindings. They can generate metadata to be used by later parsers. They can return effects to happen before or after the keybindings. Effects will no longer be run directly in extension functions but instead returned as lambdas/functions or as quoted list (to support leto.el; see below). Functions are used instead in order to support running effects before or after the keybindings are created.
    • The extension system will be implemented in a forwards-compatible to allow later improvements without breaking existing parsers. In the PoC, the extension parser functions return plists (e.g. keybind parser: (list :keybinds ... :effect ... :after-effect ...)). I'm undecided on whether to pass parser functions keyword arguments or to just recommend &rest _ (since they take few args currently, will likely not take many more, and the keyword arguments are already passed as a plist). Maybe I will use a single plist argument, so that the return value of one parser can be passed directly to the next.
    • Drop support for older Emacs versions and use newer utility functions like when-let and especially pcase-let (with plist destructuring)
  • Performance issues (#180 and #184) - these will probably matter less and less over time, but there are a couple of fundamental gotchas with general currently that can slow init time
    • Generating prefixes when :global-prefix, :non-normal-prefix, and :prefix are specified is very slow
    • General by default will delay keybindings if a keymap doesn't exist (by adding a function to after-load-functions to check if the keymap now exists when loading new elisp). This is very slow. For example, if you create a bunch of evil keybindings before loading evil, loading evil will be very slow. Maybe this can be kept as opt-in to make migration easier, but using with-eval-after-load, use-package's :config, or maybe a newly added :general-config should be recommended instead.
    • This won't be recommended for many reasons (e.g. various caveats like variables needing to be made available at expansion time since macros are not supposed to rely on the values of arguments and also the fact that it probably won't significantly improve startup time), but it will be technically possible to not even depend on any code from the rewrite at load-time by using leto.el and compiling the init file (#184). Not sure how robust this can be (so far falling back to the normal function definer on void-variable errors seems to work fine), but it will at least be fun to look into further.
  • At this point there are a lot of improvements I want to make that require other breaking changes. The syntax will mostly remain the same (or at least the previous syntax will remain an option).

Other improvements:

  • Documentation rewrite
    • Better introduction/tutorial at beginning
    • Suggested best practices
    • Full reference last
  • Leto.el
    • The vast majority of issues on the general.el repo are questions. General.el causes a lot of confusion for people not yet familiar with Emacs' keybinding system. In addition to having better introductory documentation, it would help if general.el was more transparent. An "instructor" should be provided to expand a definer to human-readable code.
    • This would help users understand how the keybinding system works/what general.el is actually doing
    • This would also help users understand whether an issue they are having is related to general.el (often it isn't)
    • The new extension system can support this with almost no extra code for leto.el (parsers just need to have slightly different behavior depending on whether called from leto or not, e.g. return a quoted form instead of a lambda for an effect)
  • Split into multiple files (load only what you use)
    • Base file will only have the basic key definer
    • Separate file for extra definer macros built on top of the basic key definer
    • Separate file for keybinding helpers
    • Separate file for leto.el
    • Separate file(s) for non-keybinding helpers
    • Separate file for some backwards-compatibility helpers to make migration easier
  • More non-keybinding configuration helpers - General has its own hook, advice, etc. helpers already with syntactic compatibility with add-hook and advice-add and extra functionality (e.g. ability to add multiple functions to multiple hooks and the ability to conditionally remove the function from the hook). I have a long list of ideas for other configuration helpers (either from my own config or yet unwritten) that I think would be better as part of a library. There are also a lot of useful helpers in Doom Emacs, for example, that would be better as part of an external library. I haven't decided if they should be in a separate repo, but I will probably just keep them in a separate file.
  • Other long unimplemented todo items like modifier prefixes (:prefix "C-") and annalist.el integration
  • Like keymap delaying, rethink other things
    • Keymaps should probably still be quoted (even though not necessary for delaying, other uses like recording the keymap name to display later with annalist)
    • Rethink extended definition syntax. If Emacs adds support for a plist definition in the future, the current syntax could be problematic. Even if it doesn't, the current syntax is not ideal. Something like key def :with (extended-def-plist...) (or the equivalent with the plist preceding the definition) could be specially handled instead. I don't really love this non-standard use of keyword argument though and need to think about things more. Maybe this can just be one option and the alternate list for each keybinding syntax below can be recommended.
    • Also consider the best syntax for binding multiple keys at at once to a single command (this can be potentially useful in some cases)
    • Consider alternate syntaxes: (<key> <command> :extended-def-keyword <arg> ...) would be much simpler to parse since the key and command are always in the same format. This will probably be the format for the internal base definer. A let-like (as opposed to setq-like) syntax will probably be optionally provided in a user-facing definer. Not sure what should be the default.
    • Rethink general-def equivalent. What should be the single recommended definer? general-def tried to be close to a drop-in replacement for several other definers, but this means it has some caveats (e.g. the need to use :start-maps or some other bogus keyword here: (general-def keymap :start-maps t key-variable #'command)). Probably it would be better have a definer that supports a variable number of positional arguments but does not try to be a drop-in replacement for other definers in order to avoid these caveats.
    • :prefix, :non-normal-prefix, and :global-prefix interaction is confusing. :prefix should always apply, and there should be :normal-prefix and :non-normal-prefix instead (old behavior can potentially be opt-in).

The rewrite will not be fully compatible with general.el (things deprecated in the readme will finally be deprecated, the extension system will be different, delaying keybindings until the keymap exists will no longer be the default, etc.), so I will probably create a new package to avoid breaking people's configs. I'd like to keep the current name, but that doesn't seem practical. I guess I could create a separate repo and not put it on MELPA, but that would probably end up causing a lot more confusion.

Possible names:

  • tyrant
  • mogul
  • baron
  • consul (previously chosen name, but it would be too confusing now with both consult and counsel)

created time in 25 days

push eventnoctuid/targets.el

denin

commit sha 082bd4f5c10ad85c8e042e67dc54ac57bfb21b1a

fix #28

view details

push time in a month

PR merged noctuid/targets.el

Fix "No evil-qoute here"

I know its dead, but this PR fixes #28

+1 -1

0 comment

1 changed file

dvzubarev

pr closed time in a month

issue closednoctuid/targets.el

Unable to replicate evil-textobj-anyblock with doc code.

(targets-define-composite-to anyblock (("(" ")" pair) ("[" "]" pair) ("{" "}" pair) ("<" ">" pair) ("\"" "\"" quote) ("'" "'" quote) ("`" "`" quote) ("“" "”" quote)) :bind t :keys "b")

Error Message: No evil-qoute here

closed time in a month

larebsyed

issue closednoctuid/general.el

Release on melpa-stable

Hi! Thank you for your great work on the package! I was wondering if you would consider cutting a release for melpa-stable repository?

closed time in a month

4lex1v

issue commentnoctuid/general.el

Release on melpa-stable

Use MELPA. The tests cover almost all functionality, and master has been stable for years. I agree with @alphapapa about MELPA stable. Almost all new commits from me will be bugfixes. I would basically be tagging a release every new commit, and MELPA and MELPA stable would be no different. At some point I will finish a minimum rewrite of general (probably under a new package name), and I will tag frequent releases for new functionality/bugfixes, but even then I won't recommend MELPA stable because I don't see how it is useful.

At best, MELPA stable protects you from intermediate, newly introduced bugs (less of a problem with tests and good development practices). This only works well with packages developed with stable releases in mind (e.g. some period of testing/bugfixes only before a release or releases can also have newly introduced bugs). My experiences has been that breaking changes are more of an issue than newly introduced bugs, and MELPA stable does nothing to help with breaking changes.

If I wanted to, for example, make an improvement that requires a breaking change in a library in another programming language, I could increment the major version to signify a breaking change (semvar). Programs using the library could lock the dependency to a major version to prevent pulling in breaking changes. Seeing that there is a new major version, someone could then read the library documentation to see the migration steps. With Emacs packages, there is no way to detect breaking changes other than looking at all packages individually. There is no way to prevent breaking changes on MELPA stable other than to never make a new release.

If you're worried about new bugs or breaking changes, I think the best solution currently is to use straight.el (or something similar, e.g. manually managed submodules) to lock versions and rollback when necessary.

4lex1v

comment created time in a month

pull request commentnoctuid/link-hint.el

Add support for buttons in buffers created by dictionary.el

Great, thanks!

mattbeshara

comment created time in a month

push eventnoctuid/link-hint.el

Matt Beshara

commit sha 4326da5617e5d04715538536b93c44a085f5dad1

Add support for buttons in buffers created by dictionary.el Add new overlay button type instead of having separate woman/man/dictionary types.

view details

push time in a month

PR merged noctuid/link-hint.el

Add support for buttons in buffers created by dictionary.el

This lets you use Link Hints for opening buffers with searches for definitions of related words.

+16 -24

0 comment

2 changed files

mattbeshara

pr closed time in a month

pull request commentnoctuid/general.el

Allow :general use-package to be given multiple times

Okay, I loosened the autorun restrictions, so hopefully the tests will automatically run from now on.

mohkale

comment created time in a month

pull request commentnoctuid/general.el

Allow :general use-package to be given multiple times

I ended up exporting everything as patches, rolling back to master, pulling in origin/master and then applying the patches on top. Out of curiosity do you know of a better way to do this? Either way now there's a single commit that has no conflicts with the base branch

I'm not sure what the best thing to do in this situation is. I would have rebased on master instead of merging master into my feature branch. If the merge causes issues with rebase afterwards, probably creating a patch vs. master is the easiest thing to do.

It should be ready to merge once the CI/CD tests finish.

It looks like it now has the old autoload parsing code instead of the code from master, so the tests are failing.

Could you also add something like this around line 883?

(it "should work with multiple :general statements"
    (use-package some-package
      :ensure nil
      :general
      (:keymaps 'general-temp-map
       "a" #'a)
      :general
      ("b" "b" :keymaps 'general-temp-map)
      :general
      ("c" #'c :keymaps 'general-temp-map)
      :general
      (general-temp-map "d" #'d)
      :general
      ('normal general-temp-map "e" #'e))
    (expect (general-test-keys nil general-temp-map
              "a" #'a
              "b" "b"
              "c" #'c
              "d" #'d))
    (expect (general-test-keys 'normal general-temp-map
              "e" #'e)))

Sorry for all the trouble. I would set the tests to autorun for this PR, but I don't see an option for that.

mohkale

comment created time in a month

Pull request review commentnoctuid/link-hint.el

Add support for buttons in buffers created by dictionary.el

 Only search the range between just after the point and BOUND."   :at-point-p #'xref--item-at-point   :copy #'link-hint--copy-xref-item) +;; ** Dictionary button+(defun link-hint--next-dictionary-button (&optional end-bound start-bound)+  (let ((pos (next-single-char-property-change (or start-bound (point))+                                               'button+                                               nil+                                               end-bound)))+    (when (< pos end-bound)+      (if-let ((button (button-at pos)))+          (overlay-start button)+        (link-hint--next-dictionary-button end-bound pos)))))++(link-hint-define-type 'dictionary-button+  :next #'link-hint--next-dictionary-button+  :vars '(dictionary-mode)

Also add dictionary-mode to the generic button type's :not-vars.

mattbeshara

comment created time in a month

Pull request review commentnoctuid/link-hint.el

Add support for buttons in buffers created by dictionary.el

     link-hint-gnus-w3m-url     link-hint-gnus-w3m-image-url     link-hint-deadgrep+    link-hint-dictionary-button

Could you also add a bullet in the readme for the new type?

mattbeshara

comment created time in a month

Pull request review commentnoctuid/link-hint.el

Add support for buttons in buffers created by dictionary.el

 Only search the range between just after the point and BOUND."   :at-point-p #'xref--item-at-point   :copy #'link-hint--copy-xref-item) +;; ** Dictionary button+(defun link-hint--next-dictionary-button (&optional end-bound start-bound)+  (let ((pos (next-single-char-property-change (or start-bound (point))+                                               'button+                                               nil+                                               end-bound)))+    (when (< pos end-bound)+      (if-let ((button (button-at pos)))

Link-hint currently supports Emacs 24.4, so don't use if-let (requires >=Emacs 25.1).

mattbeshara

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentnoctuid/general.el

Allow :general use-package to be given multiple times

 Return t if successful or a cons corresponding to the failed key and def."     (expect (general-test-keys 'normal general-temp-map               "a" #'a)))   (it "should correctly extract definitions from general definer arglists"-    (expect (plist-get (use-package-normalize/:general-                        nil-                        nil-                        '((general-def "key" #'command)))-                       :commands)-            :to-equal '(command))-    (expect (plist-get (use-package-normalize/:general

Add this test back.

mohkale

comment created time in a month

Pull request review commentnoctuid/general.el

Allow :general use-package to be given multiple times

 or if the `:no-autoload' keyword argument is non-nil, return nil."   ;; altered args will be passed to the autoloads and handler functions   (defun use-package-normalize/:general (_name _keyword general-arglists)     "Return a plist containing the original ARGLISTS and autoloadable symbols."

Could you update the docstring since all it does now is return general-arglists?

mohkale

comment created time in a month

PullRequestReviewEvent