profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dgutov/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.
Dmitry Gutov dgutov Limassol, Cyprus

bbatsov/emacs-lisp-style-guide 908

A community-driven Emacs Lisp style guide

dgutov/diff-hl 613

Emacs package for highlighting uncommitted changes

company-mode/company-quickhelp 313

Documentation popup for Company

dgutov/highlight-escape-sequences 39

Highlight escape sequences in Emacs

dgutov/bmreplace 23

Quickly replace an existing bookmark in Mozilla Firefox

dgutov/espresso-theme 14

color-theme based on the default theme for Espresso

dgutov/dot-emacs 6

My .emacs.d directory

dgutov/ClojureBlog 1

Simple Rails-like blog with comments and user authentication.

dgutov/emacs-starter-kit 1

Because the Emacs defaults are not so great sometimes.

dgutov/ethan-wspace 1

the definitive emacs customizations for people who are OCD about whitespace

issue commentcompany-mode/company-mode

Can the common part to be selected by company-complete-common get a face?

Hi @yugaego!

I still can. What backend are you currently using on the screenshots and which Emacs? With company-capf and Emacs 27 or 28, I'm only seeing the behavior like in the report.

This turns out to be a little trickier than I thought.

Popup rendering happens in company-fill-propertize. When I traced its execution with edebug, it turned out (company-call-backend 'match value) returns list of intervals ((0 . 4)). That logic lives in company-capf.

So our original company-common logic (which includes the part of the string that can still be completed) conflicts with the logic from capf which simply returns the currently matched parts of the string.

So... there might be a better choice, but to keep the "common" highlighting logic working, we can do this:

diff --git a/company.el b/company.el
index 9704a73..d055a46 100644
--- a/company.el
+++ b/company.el
@@ -2972,12 +2972,20 @@ If SHOW-VERSION is non-nil, show the version in the echo area."
       (pop copy))
     (apply 'concat pieces)))
 
+(defun company--common-or-matches (value)
+  (let ((matches (company-call-backend 'match value)))
+    (when (and matches
+               (= 1 (length matches))
+               (= 0 (caar matches))
+               (> (string-width company-common) (cdar matches)))
+      (setq matches nil))
+    (or matches
+        (and company-common (string-width company-common))
+        0)))
+
 (defun company-fill-propertize (value annotation width selected left right)
   (let* ((margin (length left))
-         (common (or (company-call-backend 'match value)
-                     (if company-common
-                         (string-width company-common)
-                       0)))
+         (common (company--common-or-matches value))
          (_ (setq value (company-reformat (company--pre-render value))
                   annotation (and annotation (company--pre-render annotation t))))
          (ann-ralign company-tooltip-align-annotations)

The alternative would be to split it into two faces, I guess. One for matching chars, another for "common" chars which will be inserted by "complete common".

But I'm not sure how to make a smooth transition, or whether we should. Perhaps simply committing the patch above and waiting for reports can answer the latter question.

sooheon

comment created time in 10 hours

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server and darcs

That's indeed unfortunate. The package was last updated several years ago, so if you have any skill with Elisp, maybe give it a look? The fix could be simple enough.

Here's the endpoint for creating a commit: https://github.com/velkyel/vc-darcs/blob/master/vc-darcs.el#L394-L412

alexDarcy

comment created time in 3 days

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server and darcs

Installing https://melpa.org/#/vc-darcs is hopefully also an option.

alexDarcy

comment created time in 3 days

issue commentcompany-mode/company-mode

Add info manual

@yugaego It's very good that it fixed itself, because I've been trying to avoid that area of knowledge for a long time. :persevere:

Work on the manual is appreciated, though I really hope you then stay around to update it as well. :slightly_smiling_face:

The other two tasks I've been eyeing (for myself, really) are more low-level: #340, #992.

#519 seems easy enough, however (I really dropped the ball on this one). Do you think "good first issue" can apply to a task like that?

skangas

comment created time in 3 days

issue commentcompany-mode/company-mode

Elisp: Additional variable binding forms like pcase-let, letrec

Hi!

company-elisp is deprecated in favor of company-capf with recent enough Emacs releases.

elisp-completion-at-point supports a lot more macros and special forms. And yeah, it uses macro expansion.

alphapapa

comment created time in 3 days

issue commentclojure-emacs/cider

Unpredictable behaviour with cider-use-xref, if LSP is also used.

is that add-hook with a depth still doesn't do anything if the function is already there

Right.

But that still allows you to remove a few lines from xref-prefer-cider. Or indeed introduce a defcustom in Cider.

deejayem

comment created time in 4 days

issue commentclojure-emacs/cider

Unpredictable behaviour with cider-use-xref, if LSP is also used.

Well, it's a hook.

The APPEND argument has been renamed in recent Emacs versions to DEPTH, with associated functionality. Either the user's snippet can use a specific depth to force one of the backends to go first, or Cider could have a defcustom which chooses said depth. It will default to 0, but the user could set it to -1, for example.

deejayem

comment created time in 4 days

issue commentclojure-emacs/cider

Evil-mode + company-mode C-n to cycle-through completion is unreliable.

If the behavior's different between C-n and M-n key bindings, the problem is likely somewhere in the Evil integration code -- and that resides inside Evil. Not much I could help there with.

If the issue can be reproduced without Evil, let me know.

Kazimazi

comment created time in 5 days

issue commentdry-rb/dry-types

Coercion of integers with trailing zero - invalid value for Integer(): "09"

This is leading zero, not trailing (wrong issue title makes searching for it harder).

DAE think that Coercible::Integer should also have this fix?

caspg

comment created time in 8 days

push eventcompany-mode/company-mode

Dmitry Gutov

commit sha 1887974e7ad50cb4884fbec27985078bba754b60

Fix search in the first LEN(company-prefix) chars of completions Reported in https://github.com/company-mode/company-mode/discussions/1211#discussioncomment-1298541.

view details

push time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

What do you think of the following cache invalidation criterium: in a pre-command hook, check if this command is self-insert-command and the syntax class is word or symbol. If not, then kill the cache.

It can work, but since the caching would be implemented inside the completion table, I think for it to concern itself with user input and particular invoked commands, is pretty dirty. But you can try and see, IDK.

astoff

comment created time in 9 days

issue commentdgutov/diff-hl

[Feature request] If point is not on a hunk, diff-hl-show-hunk will select the first hunk in current file instead.

And yup:

but now I've found there's C-u C-c C-a (M-x diff-apply-hunk with prefix argument) in vc-diff that reverses a hunk

This is also what I do on a regular basis.

One day we'll be able to commit individual hunks from VC, but not yet.

zw963

comment created time in 9 days

issue commentdgutov/diff-hl

[Feature request] If point is not on a hunk, diff-hl-show-hunk will select the first hunk in current file instead.

BTW, can you still reproduce the problem from https://github.com/dgutov/diff-hl/issues/169#issuecomment-909289157?

zw963

comment created time in 9 days

issue commentdgutov/diff-hl

[Feature request] If point is not on a hunk, diff-hl-show-hunk will select the first hunk in current file instead.

I propose please don't remove following keybinding anyway

OK, I have reverted that commit. Will have to find another solution for the smartrep/repeat-mode problem.

so, let us read code, following code is all i want to do

I see the code, and the logic doesn't make much sense to me, sorry. Why would it jump to the first hunk, if there is a hunk above it, for example? Or a hunk both above and below point.

I can add a command which will always bring you to the first hunk, however.

zw963

comment created time in 9 days

push eventdgutov/diff-hl

Dmitry Gutov

commit sha 40c89a7b0d2590b1e094128f3f1d6dc87bf14ce9

Revert "Make diff-hl-show-hunk's key bindings more consistent with the base set" This reverts commit 983366cb40923df23dd26ab38f616a1791094653.

view details

push time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

FWIW, the scheme I described implies 3, not 2. Though it would usually work with any of 1, 2, 3.

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

Right.

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

If Company doesn't call that, I'd say it's very hard to figure out something that works for all frameworks.

My point is that the caching is done in the completion backend, using its own specific logic.

Frameworks shouldn't have to know all those details.

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

I guess the natural cache invalidation trigger is completion-in-region-mode-hook. If Company doesn't call that, I'd say it's very hard to figure out something that works for all frameworks.

Suppose you complete a chain of calls, like foo.bar.baz. Is completion-in-region-mode-hook reliably called every time you type .?

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

It's curious that completion-at-point is doing all that work... I guess it needs updates on the START and END?

In Company, at least, we're calling capf repeatedly to obtain the new values of START and END, yes.

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

But the semantics of "if you notice your cache is invalid, get a new completion table" are pretty decently consistent with a lexical...

It depends on what lexical state one is talking about, but the problem "completion table dumping" has the unfortunate effect of dumping the lexical state associated with the functions returned by c-a-p-f (the completion table and the "extra properties" functions). So if one was storing their cache there, it goes out of the window.

BTW, what's an "invalidation key"? Like, state?

Some kind of derivative of the buffer state. It's hard to be very precise in an Elisp implementation (with no "real" parser), but one can include the position of the beginning of the prefix, maybe also text from bol until that position, and the first prefix itself, with which the cached completions request was made. Then a cached lookup would first compare the first two values for equality, then compare prefixes (probably by checking that the new is >= long as the initial one, and the first N characters match), and then either filter the cached completions locally, or request new ones.

astoff

comment created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

Cache the candidates in a (possibly lexical) variable.

Caching the candidates in a global dynamic variable, with some well-considered invalidation key, will probably work better.

astoff

comment created time in 9 days

issue commentcompany-mode/company-mode

lsp cant get complete candidates after error response from lsp

This is clearly either an lsp-mode problem, or a problem with the server.

The link in the last message is likely unrelated.

I suggest you try and resolve this with the lsp-mode people.

In the meantime, you can try https://github.com/nathankot/company-sourcekit. It will have fewer features, but it might be easier to set up. Or not.

wibed

comment created time in 10 days

issue commentminad/corfu

Get a new collection table when original in-buffer text is deleted/altered?

I think that's the approach lsp-mode is using already, modulo bugs. With the added complication that a server can declare a set of completions to be "incomplete", thus prohibiting reuse (e.g. step 2 should re-request).

jdtsmith

comment created time in 11 days

issue commentminad/corfu

Get a new collection table when original in-buffer text is deleted/altered?

Then do it in the backend (the lsp client).

I tend to agree.

Why should the frontend (the ui, corfu or company) decide for the backend on when the "cache" should be invalidated? And once again - the completion table is not a cache.

This is basically the reason why company is "dumping their completion table" often: if the backend contains the caches (rather than using lexical context returned with the completion table to store the cache), discarding the completion function shouldn't hurt.

We did end up caching it later (with some rather strict cache key) to help performance of certain completion functions, such as the ones using the aforementioned completion-table-with-cache. And a "completion table" can also be a list of strings, because c-a-p-f is so heavy on backward compatibility; discarding those lists of strings often is generally a good idea.

jdtsmith

comment created time in 11 days

issue commentminad/corfu

Get a new collection table when original in-buffer text is deleted/altered?

According to the LSP mode folks, VS Code caches completion results (and uses the cache when more characters are typed). So if our LSP clients do no caching at all, we'll be at disadvantage in performance.

It does seem fair to invalidate the cache aggressively if the new text is shorter than the original.

I can agree with that.

jdtsmith

comment created time in 11 days

issue commentmooz/js2-mode

Omitting parentheses and identifiers of CATCH should not raise errors

Thanks for the report, should be fixed now.

rayw000

comment created time in 11 days

issue closedmooz/js2-mode

Omitting parentheses and identifiers of CATCH should not raise errors

What happened

try {
    // ...
} catch {}
    //  ^ An error raises here saying `missing (  before catch-block condition`

Expected

No errors reported.

Version

Currently I'm on version 20210830.12 installed from MELPA.

Perhaps we should not strictly expect a catch identifier list here? https://github.com/mooz/js2-mode/blob/b913961e410dbfdc52a80d62eb4cfe7a305b4e3e/js2-mode.el#L9291-L9292

closed time in 11 days

rayw000

push eventmooz/js2-mode

Dmitry Gutov

commit sha e6a9059fc823a17496e1a5114652d92a9071a78f

Support catch without identifier Fixes #573

view details

push time in 11 days

push eventdgutov/robe

Dmitry Gutov

commit sha fd972e912d0c6c310acb2d057da1be1149937d0e

robe-call-goto-parenless: Fix WRT the recent change in parse-partial-sexp

view details

push time in 11 days