melpa/melpa 2212
Recipes and build machinery for the biggest Emacs package repo
magnars/multiple-cursors.el 1870
Multiple cursors for emacs.
bbatsov/emacs-lisp-style-guide 888
A community-driven Emacs Lisp style guide
eschulte/rinari 415
Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)
Elm mode for emacs
Clojure wrapper for the mongo-db java api
Emacs Rails mode based on projectile
nex3/haml-mode 140
Emacs mode for Haml.
Emacs rainbow delimiters mode
purcell/ac-slime 111
Emacs auto-complete plugin for Slime symbols
startedpurcell/exec-path-from-shell
started time in 3 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
It seems that in GUI mode there's never a call into encode_coding_object.
So to summarize: It seems that we generate a lot of unreachable markers in haskell-lexeme.el with looking-at. These markers cause a slow-down in encoding_coding_object which traverses the list of markers once or twice. That function is then called on redisplay on terminal mode, causing a delay on drawing each line. However, the function is never called in GUI mode.
A garbage collect would instantly bring the performance back to normal, but especially lsp-users are likely to want a high gc-cons-threshold. Also, generating this much markers causes a noticeable increase in GC delay.
Normally this wouldn't bother me as much, but I regularly trip into this the problem while doing very normal code editing - granted the scrolling speed does not get as bad as in the text-case after 4-5 cut+paste, but it's noticably sluggish nevertheless.
Assuming my hypothesis is correct:
As a user workaround I can see
- Reducing gc-cons-threshold
- Using something like
gcmh - Switching to GUI mode
For a solution: Can we reduce the amount of generating markers somehow?
comment created time in 8 hours
startedpurcell/exec-path-from-shell
started time in 8 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
I suspect this to be the culprit:
https://github.com/haskell/haskell-mode/blob/b35e8547b67f3d2c4d38ec7e7e516e3c0925352f/haskell-lexeme.el#L106
Is it possible that the frequent call of this during font locking generates a lot of match data with markers, that don't get cleaned up? If that's the case, why don't I notice the scrolling problem in GUI mode?
comment created time in 9 hours
pull request commentmelpa/melpa
It seems like much of the functionality of this package is provided by Emacs bookmarks.
comment created time in 9 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
Hi. i was asked by the issue author to help with confirming/reproducing the issue.
i'd like to report back that, after following the explicit steps and conditions here i can reproduce the issue on my machine to degrade scroll performance to the point of being sluggish in terminal mode (emacs -nw) (did not test gui)
it seems to get a lot better / came back to normal after i ran (garbage-collect), which also goes with the expected observation in the issue.
my emacs is compiled from source.
i was also asked to provide the output of C-h v system-configuration-options , which is as follows
system-configuration-options is a variable defined in ‘C source code’.
Its value is
"--with-native-compilation --with-json --with-pgtk --with-modules --with-mailutils --without-pop --without-xwidgets"
String containing the configuration options Emacs was built with.
hope it helps!
comment created time in 11 hours
startedpurcell/disable-mouse
started time in 11 hours
push eventmelpa/melpa
commit sha 51f723347f56e150852bf82d163c04aa846a3d9c
Add shellcop recipe (#7604)
push time in 14 hours
PR merged melpa/melpa
Brief summary of what the package does
Analyze info&error in shell-mode
Direct link to the package repository
https://github.com/redguardtoo/shellcop
Your association with the package
I'm the maintainer
Relevant communications with the upstream package maintainer
None needed
Checklist
<!-- Please confirm with x: -->
- [x] The package is released under a GPL-Compatible Free Software License
- [x] I've read CONTRIBUTING.org
- [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
- [x] My elisp byte-compiles cleanly
- [x]
M-x checkdocis happy with my docstrings - [x] I've built and installed the package using the instructions in CONTRIBUTING.org
- [ ] I have confirmed some of these without doing them
<!-- After submitting, please fix any problems the CI reports. -->
pr closed time in 14 hours
issue openedpurcell/package-lint
Acceptable prefixes: should `toggle-` be on the list?
The const package-lint--sane-prefixes lists some exceptional prefixes that package-lint will let slide. These have been super useful, so thanks.
It seems another common prefix is toggle, which came up in this recent MELPA PR.
toggle seems to be a popular prefix across packages -- especially builtins. One very small disadvantage I see is that there is a package called toggle indexed on MELPA. Altogether I don't see it as a problematic prefix, but I'm a consistency hobgoblin and it would be nice if the exception were codified in package-lint, should that make sense.
@rnkn fyi.
created time in 14 hours
pull request commentmelpa/melpa
Friendly ping. :) I think the only outstanding issue is the name. Naming is of course a subjective thing, so if you're adamant on simple-tree we could ask for a third party to chime in.
I notice one checkdoc regarding this error message: "Project %s already exist." which should be "Project %s already exists"
comment created time in 15 hours
pull request commentmelpa/melpa
Add recipe for frontside-windowing
Friendly ping. :)
comment created time in 15 hours
pull request commentmelpa/melpa
Add recipe for org-super-links
@toshism I'll mark this awaiting-upstream, there's no rush. (Thanks again @alphapapa for chiming in.)
comment created time in 15 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
Underlying issue for the test-case appears to be a large accumulation of unreachable markers in the buffer. encode_coding_object traverses the singly linked of markers at least once, potentially twice.
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/coding.c?h=emacs-27.1&id=86d8d76aa36037184db0b2897c434cdaab1a9ae8#n8281
In the degenerate case this singly linked list can contain millions of elements, causing the slowdown.
What is haskell-font-lock.el doing to make this problem so apparent, even when editing smaller code regions?
comment created time in 17 hours
startedpurcell/emacs.d
started time in 17 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
gprof agrees:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
96.23 160.67 160.67 32275 4.98 4.98 encode_coding_object
5ms per call into encode_coding_object makes for absolute horrid performance I guess.
comment created time in 18 hours
issue commenthaskell/haskell-mode
Degrading scroll performance in terminal mode
It seems that 75% of the time is spent in encode_coding_object
Attached you can find the perf_events report and flamegraph.
perf_report.gz out.svg.gz out.perf.gz
Samples: 4K of event 'cycles'
# Event count (approx.): 112485425315
#
# Children Self Samples Command Shared Object Symbol
# ........ ........ ............ ............... ..................... ..............................................
#
99.67% 0.00% 0 .emacs-27.1-wra [unknown] [k] 0x41fd89415541f689
|
---0x41fd89415541f689
__libc_start_main
main
:
recursive_edit_1
command_loop
internal_catch
internal_condition_case
command_loop_1
|
|--77.34%--read_key_sequence
| |
| --77.28%--read_char
| |
| --77.22%--redisplay_internal
| |
| |--75.83%--update_frame
| | update_frame_1
| | update_frame_line
| | tty_write_glyphs
| | |
| | --75.81%--encode_terminal_code
| | --75.76%--encode_coding_object
| |
comment created time in 19 hours
issue openedhaskell/haskell-mode
Degrading scroll performance in terminal mode
The Problem
Since I switched to emacs I noticed how scrolling sporadically became worse. At times, it would take 3-4s to redraw 40 lines of code.
Apparent relevant factors
After doing a lot of analyzing I narrowed it down to the following combination of things:
- Emacs must run in terminal, in GUI either the problem is not as apparent or its non-existant.
- gc-cons-threshold must be set to a high value. LSP users likely have something like
(setq gc-cons-threshold 100000000) haskell-modeandfont-lock-modemust be enabled- Do some text editing
Watch drawing lines become slower. The presence of constructor names seems especially bad. Note, that the entire line is drawn much slower, so if you vertically tile your emacs to have some unrelated buffer on the right hand side, then the entire line with many data constructors on the left hand window will be drawn slowly.
- If you then cause a
(garbage-collect), scrolling becomes fast again.
Reproduce
Locally I used emacs 27.1 installed through the emacs nix overlay:
<details> <summary>Click to see/use my nixos module</summary> <p>
{ config, pkgs, ... }:
let
emacsOverlay = import (builtins.fetchTarball {
# Descriptive name to make the store path easier to identify
name = "emacs-overlay-2020-09-11";
# Commit hash for nixos-unstable as of 2018-09-12
url = https://github.com/nix-community/emacs-overlay/archive/a69588a3f7de6d68f20cea21562ab7f6f91a400a.tar.gz;
# Hash obtained using `nix-prefetch-url --unpack <url>`
sha256 = "180jp31zfrlhnz490x6hckz6z3bvfxwz1613cg4zmf0lrflrl3gp";
});
myEmacs = pkgs.emacs;
emacsWithPackages = (pkgs.emacsPackagesGen myEmacs).emacsWithPackages;
emacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
# melpa stable
ripgrep
magit
# dockerfile-mode
# markdown-mode
# yaml-mode
# json-mode
# go-mode
# nix-mode
use-package
projectile
# direnv
# swiper
# ox-gfm
# pdf-tools
]) ++ (with epkgs.melpaPackages; [
# melpa unstable
solarized-theme
gruvbox-theme
company
counsel
counsel-projectile
ivy
evil
evil-collection
evil-magit
haskell-mode
lsp-mode
lsp-ui
lsp-haskell
lsp-treemacs
treemacs
flycheck
]) ++ (with epkgs.elpaPackages; [
# elpa packages
undo-tree
]) ++ [
# main packages
]);
in
{
nixpkgs.overlays = [emacsOverlay];
services.emacs.enable = true;
services.emacs.install = true;
services.emacs.defaultEditor = true;
services.emacs.package = emacs;
}
</p> </details>
- Ensure you do not have
undo-tree-modeenabled. This minor mode causes frequent garbage collections with the test-case, leading to inconsistent behavior. - Download the attached test file
- Set
(setq garbage-collection-messages t)to have emacs tell you if a GC is run Note: This is just for your own sanity so you do know if for some reason there's an unexpected. - Set
(setq gc-cons-threshold most-positive-fixnum)Note: We use the highest value to ensure the GC doesn't interfere with our testcase due to some unforseen circumstances. It's an unreasonable value for the real world. - Repeatedly
cut+pastethe block below the definition ofinfo. Ideally keep a small terminal (say 80x24), this lets you see the redisplay of the definitions ofinfo Attr ...nicely duringcut+paste.
Watch the performance degrade with every cut+paste.
- Run a
(garbage-collect)and watch performance be fast again.
Notes of interest:
- If the block at the end is wrapped inside a comment, performance stays stable during
cut+paste - If the block at the end is just un-font-locked, performance degrades during
cut+paste - The redisplay degradation is particularly linked to the font locking on data constructors.
If we add more data constructors in those definitions of
info, then the performance degradation is much worse. - The redisplay performance extends to the entire frame, not just the buffer. Two ways to demonstrate this: If you resize the frame to full screen, watch how every line including toolbar and mode line is drawn slowly too. You can also create horizontal/vertical split windows, and watch how these get redrawn slowly too when the frame is switched between full screen and windowed.
- The problem is reproducible with
undo-tree-modepresent,(setq gc-cons-threshold 100000000)and normal editing of text. Often writing a 60 line region can cause quite bad performance degradation already, it's just more inconsistent. This I want to point out before someone makes a comment about how repeatedlycut+pasteon 10k lines of code is not normal emacs usage. This is just a synthesized test case with a clear communicatable description how to reproduce.
- The emacs profiler does not help at all.
- During degraded performance, the CPU usage spikes to 100% while scrolling.
Profiler output
If the performance has degraded, running the profiler while scrolling up and down for a minute gives these CPU and Memory reports
CPU Profiler output
<details> <summary>Click me to expand!</summary> <p>
Function CPU samples %
- command-execute 3417 99%
- call-interactively 3417 99%
- funcall-interactively 3284 96%
- execute-extended-command 2300 67%
- sit-for 2287 66%
- redisplay 2287 66%
+ redisplay_internal (C function) 1 0%
+ command-execute 12 0%
scroll-down-command 534 15%
- scroll-up-command 450 13%
+ scroll-up 1 0%
+ byte-code 133 3%
+ evil-repeat-post-hook 1 0%
evil--jump-hook 1 0%
+ timer-event-handler 1 0%
+ ... 0 0%
</details> </p>
Memory profiler output
<details> <summary>Click me to expand!</summary> <p>
Function Bytes %
- command-execute 8,755,700 99%
- call-interactively 8,755,700 99%
- byte-code 4,469,695 50%
- read-extended-command 4,469,695 50%
- completing-read 4,469,695 50%
- ivy-completing-read 4,469,695 50%
- ivy-read 4,469,695 50%
- read-from-minibuffer 2,628,499 29%
+ ivy--queue-exhibit 2,068,301 23%
+ command-execute 49,096 0%
+ redisplay_internal (C function) 12,416 0%
+ minibuffer-inactive-mode 7,392 0%
+ #<compiled 0x472e8f9> 1,056 0%
+ undo-auto--add-boundary 1,056 0%
+ undo-auto--undoable-change 72 0%
+ ivy--reset-state 256,404 2%
+ ivy-call 1,056 0%
+ ivy--update-prompt 1,024 0%
- funcall-interactively 4,286,005 48%
- execute-extended-command 4,259,293 48%
- command-execute 3,791,263 43%
- call-interactively 3,791,263 43%
- funcall-interactively 3,791,247 43%
profiler-stop 3,790,592 43%
profiler-start 655 0%
+ sit-for 273,374 3%
+ scroll-down-command 15,960 0%
+ scroll-up-command 10,752 0%
+ redisplay_internal (C function) 23,224 0%
+ jit-lock--antiblink-post-command 8,360 0%
+ timer-event-handler 6,200 0%
evil--jump-handle-buffer-crossing 2,112 0%
+ global-font-lock-mode-check-buffers 1,056 0%
+ internal-echo-keystrokes-prefix 1,056 0%
... 0 0%
</details> </p>
GC Output
I first did cut+paste to degrade performance, then executed two (garbage-collect) in a row
The first, which fixed performance, gave us the following output
<details> <summary>First GC (After degraded performance): Click me to expand!</summary> <p>
((conses 16 4979055 645610)
(symbols 48 93078 29)
(strings 32 158480 15678)
(string-bytes 1 8876291)
(vectors 16 92580)
(vector-slots 8 1958997 416166)
(floats 8 336 1527)
(intervals 56 1006222 9317)
(buffers 1000 42))
</p> </details>
Second GC, immediately again. This is just to observe whether the first GC has collected huge amounts of memory. Note: It did not. The output is very similar to that of the run before. <details> <summary>First GC (After degraded performance): Click me to expand!</summary> <p>
((conses 16 4947118 644997)
(symbols 48 93078 29)
(strings 32 158477 15588)
(string-bytes 1 8875403)
(vectors 16 92579)
(vector-slots 8 1958985 414138)
(floats 8 336 1527)
(intervals 56 1006220 9301)
(buffers 1000 42))
</p> </details>
created time in 21 hours
startedpurcell/mmm-mode
started time in a day
issue commentpurcell/emacs.d
The order of company candidates is incorrect in Emacs lisp mode
Hi, @purcell
Now we have changed the completion style to (setq completion-styles '(basic partial-completion orderless)) globally, this also affect the completion in minibuffer. Now the behavior is like this:
I think it is better to set minibuffer completion-styles to use only orderless to get a better experience.
something like this would work.
(defun sanityinc/use-orderless-in-minibuffer ()
(interactive)
(setq-local completion-styles '(orderless)))
(add-hook 'minibuffer-setup-hook 'sanityinc/use-orderless-in-minibuffer)
Now it the behavior is like this:
comment created time in a day
push eventmelpa/melpa
commit sha b6d136b1033d9afdea965ab07ba7c05e9ecf56e5
Add ol-notmuch recipe
push time in a day
PR opened melpa/melpa
Brief summary of what the package does
An Emacs major-mode for chess engine interaction. This is a dependency for the more interesting library pygn-mode, to be submitted separately.
Direct link to the package repository
https://github.com/dwcoates/uci-mode
Your association with the package
A contributor, on behalf of @dwcoates .
Relevant communications with the upstream package maintainer
None needed.
Checklist
<!-- Please confirm with x: -->
- [x] The package is released under a GPL-Compatible Free Software License
- [x] I've read CONTRIBUTING.org
- [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
- [x] My elisp byte-compiles cleanly
- [x]
M-x checkdocis happy with my docstrings - [x] I've built and installed the package using the instructions in CONTRIBUTING.org
- [ ] I have confirmed some of these without doing them
<!-- After submitting, please fix any problems the CI reports. -->
pr created time in a day
startedpurcell/ibuffer-vc
started time in a day
PR opened melpa/melpa
Brief summary of what the package does
A minor mode to keep repositories in sync using the rsync command line tool.
Direct link to the package repository
https://github.com/r-zip/rsync-mode
Your association with the package
I am the primary author. The only other contributor is ajwhite445. @ajwhite445
Relevant communications with the upstream package maintainer
None needed.
Checklist
<!-- Please confirm with x: -->
- [x] The package is released under a GPL-Compatible Free Software License
- [x] I've read CONTRIBUTING.org
- [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
- [x] My elisp byte-compiles cleanly
- [x]
M-x checkdocis happy with my docstrings - [x] I've built and installed the package using the instructions in CONTRIBUTING.org
- [ ] I have confirmed some of these without doing them
<!-- After submitting, please fix any problems the CI reports. -->
pr created time in 2 days
Pull request review commenttezos-checker/checker
Initial stress test for liquidation auction
def call_checker_endpoint(name, param, amount=0): print(json.dumps(gas_costs_sorted, indent=4)) +class LiquidationsStressTest(SandboxedTestCase):+ def test_liquidations(self):+ print("Deploying the mock oracle.")+ oracle = deploy_contract(+ self.client,+ source_file=os.path.join(PROJECT_ROOT, "util/mock_oracle.tz"),+ initial_storage=(self.client.key.public_key_hash(), 1000000),+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deploying ctez contract.")+ ctez = deploy_ctez(+ self.client,+ ctez_dir=os.path.join(PROJECT_ROOT, "vendor/ctez"),+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deploying Checker.")+ checker = deploy_checker(+ self.client,+ checker_dir=CHECKER_DIR,+ oracle=oracle.context.address,+ ctez=ctez["fa12_ctez"].context.address,+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deployment finished.")++ def call_endpoint(contract, name, param, amount=0):+ print("Calling", contract.key.public_key_hash(), "/", name, "with", param)+ return inject(+ self.client,+ getattr(contract, name)(param)+ .with_amount(amount)+ .as_transaction()+ .autofill(ttl=MAX_OPERATIONS_TTL)+ .sign(),+ )++ def call_bulk(bulks, *, chunk_size):+ chunks = [+ bulks[i : i + chunk_size] for i in range(0, len(bulks), chunk_size)+ ]+ for chunk_no, chunk in enumerate(chunks, 1):
This isn't super critical, but I am wondering if using the term "batch" instead of "chunk" would be more descriptive here since we also use "chunk" in our deployment script to describe chunks of bytes.
comment created time in 2 days
Pull request review commenttezos-checker/checker
Initial stress test for liquidation auction
-{ doCheck ? false }:+{ doCheck ? false, e2eTestsHack ? false }:
Nice :smile:
comment created time in 2 days
Pull request review commenttezos-checker/checker
Initial stress test for liquidation auction
def call_checker_endpoint(name, param, amount=0): print(json.dumps(gas_costs_sorted, indent=4)) +class LiquidationsStressTest(SandboxedTestCase):+ def test_liquidations(self):+ print("Deploying the mock oracle.")+ oracle = deploy_contract(+ self.client,+ source_file=os.path.join(PROJECT_ROOT, "util/mock_oracle.tz"),+ initial_storage=(self.client.key.public_key_hash(), 1000000),+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deploying ctez contract.")+ ctez = deploy_ctez(+ self.client,+ ctez_dir=os.path.join(PROJECT_ROOT, "vendor/ctez"),+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deploying Checker.")+ checker = deploy_checker(+ self.client,+ checker_dir=CHECKER_DIR,+ oracle=oracle.context.address,+ ctez=ctez["fa12_ctez"].context.address,+ ttl=MAX_OPERATIONS_TTL,+ )++ print("Deployment finished.")++ def call_endpoint(contract, name, param, amount=0):+ print("Calling", contract.key.public_key_hash(), "/", name, "with", param)+ return inject(+ self.client,+ getattr(contract, name)(param)+ .with_amount(amount)+ .as_transaction()+ .autofill(ttl=MAX_OPERATIONS_TTL)+ .sign(),+ )++ def call_bulk(bulks, *, chunk_size):
Not sure if we need the * in this signature
comment created time in 2 days