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

joaotavora/eglot 1213

A client for Language Server Protocol servers

joaotavora/autopair 202

Automagically pair braces and quotes in emacs like TextMate

joaotavora/darkroom 110

Simple distraction-free editing

joaotavora/efire 5

A campfire client for emacs

joaotavora/cl-guard 4

A uniform interface to your file and event watching needs in common lisp.

joaotavora/ecco 4

ecco is a port of docco for emacs

joaotavora/blip 2

Automatically find and run tests in emacs

joaotavora/edice 2

Why would you want to roll dice in Emacs?

joaotavora/ac-slime 0

Emacs auto-complete plugin for Slime symbols

joaotavora/ac-sly 0

Emacs auto-complete source for SLY's Common Lisp IDE

issue commentjoaotavora/sly

describe-mode (С-h m) is not working for sly-db buffers

Thanks. Can someone make a pull request?

Valera

comment created time in 21 hours

issue closedjoaotavora/eglot

Cannot find definitions with haskell-language-server and darcs

<!-- Hello there, prospective issue reporter! Your bug reports are very valuable 💛 💛 💛. They really are, and Eglot couldn't be made without them. But there are lots of bugs and so little time. So:

    PLEASE - DO NOT - REMOVE OR SKIP PARTS OF THIS TEMPLATE.

 👉 Need help configuring or understanding Emacs, Eglot, or LSP?
   Have an idea for a feature?  Please DON'T OPEN A NEW ISSUE!

   Head to https://github.com/joaotavora/eglot/discussions to
   discuss.  Start a new discussion, there are no templates there,
   you can just speak your mind.

 👉 Maybe your issue is already solved or worked around.  Have glance at
   https://github.com/joaotavora/eglot/issues?q=is%3Aissue+label%3Aworkaround

 👉 You can also make an Emacs bug report, which can also be used
   for general discussion.  You'll potentially reach more people
   this way.  You can do it via `M-x report-emacs-bug` or just
   send email to `bug-gnu-emacs@gnu.org`.  Be sure to `CC:` (or
   better, `X-Debbugs-CC:` ) Eglot's maintainer, currently
   `joaotavora@gmail.com`.

 To make an issue, you need to provide some elements, which aren't
 hard to find.  Can't find all the elements for this template?
 No problem, just make a discussion 👆.

 Here's an example of a 👌 fine issue report following this template:
 https://github.com/joaotavora/eglot/issues/696
 
 If you don't provide the needed elements, WE MAY CLOSE THE ISSUE
 JUST LIKE THAT 😐. 

-->

  • Server used: haskell-language-server
  • Emacs version: 28.0.50
  • Operating system: FreeBsd 13.0
  • Eglot version: 1.7
  • Eglot installation method: straight.el
  • Using Doom: No

LSP transcript - M-x eglot-events-buffer (mandatory unless Emacs inoperable)

<!-- DO NOT SKIP: Include the invaluable LSP transcript.

 Inside Emacs, you can display that buffer with the M-x
 eglot-events-buffer command. It contains the JSONRPC messages
 exchanged between client and server, as well as the messages the
 server prints to stderr.  Copy that text and paste it below as a
 formatted code block
 (https://help.github.com/articles/creating-and-highlighting-code-blocks/)). -->
[client-request] (id:1) Sun Sep 12 16:27:20 2021:
(:jsonrpc "2.0" :id 1 :method "initialize" :params
	  (:processId 17917 :rootPath "/usr/home/alex/test/" :rootUri "file:///usr/home/alex/test" :initializationOptions #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8125 data
																	())
		      :capabilities
		      (:workspace
		       (:applyEdit t :executeCommand
				   (:dynamicRegistration :json-false)
				   :workspaceEdit
				   (:documentChanges :json-false)
				   :didChangeWatchedFiles
				   (:dynamicRegistration t)
				   :symbol
				   (:dynamicRegistration :json-false)
				   :configuration t)
		       :textDocument
		       (:synchronization
			(:dynamicRegistration :json-false :willSave t :willSaveWaitUntil t :didSave t)
			:completion
			(:dynamicRegistration :json-false :completionItem
					      (:snippetSupport :json-false)
					      :contextSupport t)
			:hover
			(:dynamicRegistration :json-false :contentFormat
					      ["plaintext"])
			:signatureHelp
			(:dynamicRegistration :json-false :signatureInformation
					      (:parameterInformation
					       (:labelOffsetSupport t)
					       :activeParameterSupport t))
			:references
			(:dynamicRegistration :json-false)
			:definition
			(:dynamicRegistration :json-false :linkSupport t)
			:declaration
			(:dynamicRegistration :json-false :linkSupport t)
			:implementation
			(:dynamicRegistration :json-false :linkSupport t)
			:typeDefinition
			(:dynamicRegistration :json-false :linkSupport t)
			:documentSymbol
			(:dynamicRegistration :json-false :hierarchicalDocumentSymbolSupport t :symbolKind
					      (:valueSet
					       [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26]))
			:documentHighlight
			(:dynamicRegistration :json-false)
			:codeAction
			(:dynamicRegistration :json-false :codeActionLiteralSupport
					      (:codeActionKind
					       (:valueSet
						["quickfix" "refactor" "refactor.extract" "refactor.inline" "refactor.rewrite" "source" "source.organizeImports"]))
					      :isPreferredSupport t)
			:formatting
			(:dynamicRegistration :json-false)
			:rangeFormatting
			(:dynamicRegistration :json-false)
			:rename
			(:dynamicRegistration :json-false)
			:publishDiagnostics
			(:relatedInformation :json-false))
		       :experimental #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8125 data
						   ()))))
[stderr] No 'hie.yaml' found. Try to discover the project type!
[stderr] Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 1.2.0.0 x86_64 ghc-8.10.7
[stderr] Current directory: /usr/home/alex/test
[stderr] Operating system: freebsd
[stderr] Arguments: ["--lsp"]
[stderr] Cradle directory: /usr/home/alex/test
[stderr] Cradle type: Default
[stderr] 
[stderr] 
[stderr] Tool versions found on the $PATH
[stderr] cabal:		3.4.0.0
[stderr] stack:		2.7.1
[stderr] ghc:		8.10.7
[stderr] 
[stderr] 
[stderr] Consulting the cradle to get project GHC version...
[stderr] Project GHC version: 8.10.7
[stderr] haskell-language-server exe candidates: ["haskell-language-server-8.10.7","haskell-language-server"]
[stderr] Launching haskell-language-server exe at:/usr/local/bin/haskell-language-server-8.10.7
[stderr] nil
[stderr] haskell-language-server version: 1.2.0.0 (GHC: 8.10.7) (PATH: /usr/local/bin/haskell-language-server)
[stderr] Starting (haskell-language-server)LSP server...
[stderr]   with arguments: GhcideArguments {argsCommand = LSP, argsCwd = Nothing, argsShakeProfiling = Nothing, argsTesting = False, argsExamplePlugin = False, argsDebugOn = False, argsLogFile = Nothing, argsThreads = 0, argsProjectGhcVersion = False}
[stderr]   with plugins: [PluginId "pragmas",PluginId "floskell",PluginId "fourmolu",PluginId "tactics",PluginId "ormolu",PluginId "stylish-haskell",PluginId "retrie",PluginId "brittany",PluginId "class",PluginId "haddockComments",PluginId "eval",PluginId "importLens",PluginId "refineImports",PluginId "moduleName",PluginId "hlint",PluginId "splice",PluginId "ghcide-hover-and-symbols",PluginId "ghcide-code-actions-imports-exports",PluginId "ghcide-code-actions-type-signatures",PluginId "ghcide-code-actions-bindings",PluginId "ghcide-code-actions-fill-holes",PluginId "ghcide-completions",PluginId "ghcide-type-lenses",PluginId "ghcide-core"]
[stderr]   in directory: /usr/home/alex/test
[stderr]  Starting LSP server...
[stderr] If you are seeing this in a terminal, you probably should have run WITHOUT the --lsp option!
[stderr] Started LSP server in 0.00s
[stderr] setInitialDynFlags cradle: Cradle {cradleRootDir = "/usr/home/alex/test", cradleOptsProg = CradleAction: Default}
[stderr] 2021-09-12 16:27:21.167236536 [ThreadId 5] INFO hls:	Registering ide configuration: IdeConfiguration {workspaceFolders = fromList [NormalizedUri (-6096344772590460870) "file:///usr/home/alex/test"], clientSettings = hashed (Just (Object (fromList [])))}
[server-reply] (id:1) Sun Sep 12 16:27:21 2021:
(:result
 (:capabilities
  (:foldingRangeProvider :json-false :hoverProvider t :typeDefinitionProvider t :colorProvider :json-false :renameProvider :json-false :declarationProvider :json-false :executeCommandProvider
			 (:commands
			  ["17926:tactics:tacticsAutoCommand" "17926:tactics:tacticsIntrosCommand" "17926:tactics:tacticsDestructCommand" "17926:tactics:tacticsDestructPunCommand" "17926:tactics:tacticsHomomorphismCommand" "17926:tactics:tacticsDestructLambdaCaseCommand" "17926:tactics:tacticsHomomorphismLambdaCaseCommand" "17926:tactics:tacticsDestructAllCommand" "17926:tactics:tacticsUseDataConCommand" "17926:tactics:tacticsRefineCommand" "17926:tactics:tacticsBeginMetaprogramCommand" "17926:tactics:tacticsRunMetaprogramCommand" "17926:tactics:wingman.emptyCase" "17926:retrie:retrieCommand" "17926:class:addMinimalMethodPlaceholders" "17926:eval:evalCommand" "17926:importLens:ImportLensCommand" "17926:refineImports:RefineImportLensCommand" "17926:moduleName:updateModuleName" "17926:hlint:applyOne" "17926:hlint:applyAll" "17926:splice:expandTHSpliceInplace" "17926:ghcide-completions:extendImport" "17926:ghcide-type-lenses:typesignature.add"])
			 :documentRangeFormattingProvider t :documentHighlightProvider t :implementationProvider :json-false :completionProvider
			 (:resolveProvider :json-false :triggerCharacters
					   ["."])
			 :workspace
			 (:workspaceFolders
			  (:supported t :changeNotifications t))
			 :definitionProvider t :documentFormattingProvider t :referencesProvider t :selectionRangeProvider :json-false :codeLensProvider
			 (:resolveProvider :json-false :workDoneProgress :json-false)
			 :documentSymbolProvider t :textDocumentSync
			 (:save nil :change 2 :openClose t)
			 :workspaceSymbolProvider t :codeActionProvider t))
 :id 1 :jsonrpc "2.0")
[client-notification] Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :method "initialized" :params #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8125 data
							    ()))
[client-notification] Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :method "textDocument/didOpen" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs" :version 0 :languageId "haskell" :text "module main where\n\nmyFunc = print \"coucou\"\n\nmain = do\n  myFuc\n")))
[client-notification] Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :method "workspace/didChangeConfiguration" :params
	  (:settings nil))
[stderr] 2021-09-12 16:27:21.176135106 [ThreadId 47] INFO hls:	Consulting the cradle for "test.hs"
[stderr] 2021-09-12 16:27:21.17625225 [ThreadId 47] WARNING hls:	No [cradle](https://github.com/mpickering/hie-bios#hie-bios) found for test.hs.
[stderr]  Proceeding with [implicit cradle](https://hackage.haskell.org/package/implicit-hie).
[stderr] You should ignore this message, unless you see a 'Multi Cradle: No prefixes matched' error.
[server-request] (id:0) Sun Sep 12 16:27:21 2021:
(:id 0 :method "client/registerCapability" :params
     (:registrations
      [(:id "globalFileWatches" :method "workspace/didChangeWatchedFiles" :registerOptions
	    (:watchers
	     [(:kind 7 :globPattern "**/*.hs")
	      (:kind 7 :globPattern "**/*.hs-boot")
	      (:kind 7 :globPattern "**/*.lhs")
	      (:kind 7 :globPattern "**/*.lhs-boot")]))])
     :jsonrpc "2.0")
[client-reply] (id:0) Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :id 0 :result nil)
[server-notification] Sun Sep 12 16:27:21 2021:
(:method "window/logMessage" :params
	 (:message "lsp:configuration parse error. NotificationMessage {_jsonrpc = \"2.0\", _method = SWorkspaceDidChangeConfiguration, _params = DidChangeConfigurationParams {_settings = Null}} \"parsing Config failed, expected Object, but encountered Null\"" :type 1)
	 :jsonrpc "2.0")
[stderr] Output from setting up the cradle Cradle {cradleRootDir = "/usr/home/alex/test", cradleOptsProg = CradleAction: Default}
[stderr] 2021-09-12 16:27:21.287820685 [ThreadId 47] INFO hls:	Using interface files cache dir: /home/alex/.cache/ghcide/main-da39a3ee5e6b4b0d3255bfef95601890afd80709
[stderr] 2021-09-12 16:27:21.287989746 [ThreadId 47] INFO hls:	Making new HscEnv[main]
[server-notification] Sun Sep 12 16:27:21 2021:
(:method "textDocument/publishDiagnostics" :params
	 (:diagnostics
	  [(:range
	    (:end
	     (:character 11 :line 0)
	     :start
	     (:character 7 :line 0))
	    :message "parse error on input ‘main’" :severity 1 :source "parser")]
	  :uri "file:///usr/home/alex/test/test.hs" :version 0)
	 :jsonrpc "2.0")
[client-request] (id:2) Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :id 2 :method "textDocument/hover" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs")
	   :position
	   (:line 0 :character 0)))
[client-request] (id:3) Sun Sep 12 16:27:21 2021:
(:jsonrpc "2.0" :id 3 :method "textDocument/documentHighlight" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs")
	   :position
	   (:line 0 :character 0)))
[stderr] 2021-09-12 16:27:21.528001973 [ThreadId 86] INFO hls:	finish: Wingman.getMetaprogramsAtSpan.TypeCheck (took 0.00s)
[server-reply] (id:2) Sun Sep 12 16:27:21 2021:
(:result nil :id 2 :jsonrpc "2.0")
[server-reply] (id:3) Sun Sep 12 16:27:21 2021:
(:result
 []
 :id 3 :jsonrpc "2.0")
[client-request] (id:4) Sun Sep 12 16:27:27 2021:
(:jsonrpc "2.0" :id 4 :method "textDocument/hover" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs")
	   :position
	   (:line 5 :character 4)))
[client-request] (id:5) Sun Sep 12 16:27:27 2021:
(:jsonrpc "2.0" :id 5 :method "textDocument/documentHighlight" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs")
	   :position
	   (:line 5 :character 4)))
[stderr] 2021-09-12 16:27:27.095598197 [ThreadId 102] INFO hls:	finish: Wingman.getMetaprogramsAtSpan.TypeCheck (took 0.00s)
[server-reply] (id:4) Sun Sep 12 16:27:27 2021:
(:result nil :id 4 :jsonrpc "2.0")
[server-reply] (id:5) Sun Sep 12 16:27:27 2021:
(:result
 []
 :id 5 :jsonrpc "2.0")
[client-request] (id:6) Sun Sep 12 16:27:27 2021:
(:jsonrpc "2.0" :id 6 :method "textDocument/definition" :params
	  (:textDocument
	   (:uri "file:///usr/home/alex/test/test.hs")
	   :position
	   (:line 5 :character 4)))
[server-reply] (id:6) Sun Sep 12 16:27:27 2021:
(:result
 []
 :id 6 :jsonrpc "2.0")

Backtrace (mandatory, unless no error message seen or heard):

<!-- DO NOT SKIP:

 If Emacs errored (you saw -- and possibly heard -- an error message), 
 make sure you repeat the process after enabling backtraces with 
 `M-x toggle-debug-on-error`.  The backtrace buffer contains text that 
 you should include here, again as a formatted code block. 

--> The errors is from haskell-language-server

Minimal configuration (mandatory)

<!-- DO NOT SKIP:

 Are you using Doom Emacs or Spacemacs Emacs or some very special 
 pimped-out Emacs?  That's fine, but for this report we need to be 
 able to replicate the problem JUST AS IT HAPPENED TO YOU.  

 We can't and don't have time to replicate your complex configuration 
 and environment, so you need to provide a MINIMAL, REPRODUCIBLE and 
 COMPLETE recipe.
 
 How to do this?  The easiest recipes just start Emacs from the shell:

-->

emacs -Q 

<!-- Then you add a bit of Elisp code that can be typed into scratch -->

(defvar bootstrap-version)
(let ((bootstrap-file
     (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
    (bootstrap-version 5))
(unless (file-exists-p bootstrap-file)
  (with-current-buffer
      (url-retrieve-synchronously
       "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
       'silent 'inhibit-cookies)
    (goto-char (point-max))
    (eval-print-last-sexp)))
(load bootstrap-file nil 'nomessage))

(setq straight-use-package-by-default 't)
(straight-use-package 'use-package)

(use-package project)
(use-package eglot
 :config
 (add-hook 'haskell-mode-hook 'eglot-ensure))
(use-package haskell-mode)

<!-- WHEW!! THANK YOU!

  For some bugs, all this may seem like overkill but believe us,
  very often what seems like a "clear issue" is actually specific
  to some details of your setup. Having a runnable reproduction
  not only "proves" your bug to us but also allows us to spend all
  our effort fixing the bug instead of struggling to understand
  your issue.

  Anyway, after you've launched Emacs + Eglot that please explain
  what options you clicked on or what commands you entered, in a
  way that is clear to the Eglot maintainers so they can replicate
  the problem JUST AS IT HAPPENED TO YOU.
  
  If this requires some bits of .emacs or init.el configuration,
  you need to add them (just as in the example above)
  
  If reproducing your error requires others files and or programs,
  you NEED TO ADD snippets for them or provide links to them.

  Some users also provide whole Git repositories perfectly
  "sandboxing" a configuration and setup.  If you're confident on
  how do to this, that also works.
  
  Thank you very much.
  
  (Adapted this template from RollupJS's bug tracker). -->

Minimal example reproducing the problem

With this haskell file:

module main where

myFunc = print "coucou"

main = do
  myFunc

Going to myFunc and pressing 'M-.' (aka xref-find-definitions) yields user-error: No definitions found for: LSP identifier at point.

closed time in 3 days

alexDarcy

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server and darcs

Maybe you can teach it to do that, even if just in your .emacs. See the documentation for project-find-functions and try to type some basic Elisp for finding the Darcs root directory (maybe a special file is kept there).

In the mantime, I'm closing this, as it's not strictly Eglot-related, but we can keep discussing of course.

alexDarcy

comment created time in 3 days

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server

@alexDarcy I don't know if it is "right", but it does seem plausible. Now, Eglot doesn't use Git directly to find the project root, it uses something called project.el, which then uses a VCS-specific adapter to find project roots, and that adapter would, I think, be able to find project roots for multiple VCS systems. So there should, in theory, be a way for Eglot to use your Darcs home dir as the rootPath. I would even expect that to function automatically without any intervention. I'll call @dgutov who is the maintainer of project.el and also a collaborator to Eglot, in hopes that he can shed light on the matter, as I'm not a Darcs user.

alexDarcy

comment created time in 3 days

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server

@alexDarcy So there's no suspicion of Eglot bug/misbehaviour anymore?

alexDarcy

comment created time in 4 days

issue commentjoaotavora/eglot

Cannot find definitions with haskell-language-server

Thanks @leungbk for having a look at this. From what I can tell, it could be a server problem, or it could be some kind of missing configuration that can be added by the user to eglot-workspace-configuration for some server versions. Of course we have to discover what that would be. @alexDarcy if you have tried this with another client and have the LSP transcript for that successful session, it would be helpful.

alexDarcy

comment created time in 4 days

push eventjoaotavora/emacs

João Távora

commit sha 21ca8f260d9d5b64f9b6baae64227a180993c391

fixup

view details

João Távora

commit sha 636e0ed309cd07d172f4594a62aa1973c027fb35

And closer

view details

João Távora

commit sha 25766c2fec194bbb8e6fb6ee6e93a3358c5dbb6c

Update doc

view details

push time in 7 days

push eventjoaotavora/emacs

Dmitry Gutov

commit sha b2c44706b69fff4b80cfd78a5cd94a3da1c87fa7

Support tags-apropos-additional-actions in etags Xref backend * lisp/progmodes/etags.el (xref-etags-apropos-location): New class. (xref-location-marker): New method definition. (xref-make-etags-apropos-location): New function. (etags--xref-apropos-additional): New function. (xref-backend-apropos): Use it here.

view details

Dmitry Gutov

commit sha 44ba8278a64dec8f3fbec7c5eec613013d418f4c

* lisp/progmodes/ruby-mode.el (ruby-current-indentation): Tweak obsoletion.

view details

João Távora

commit sha 02088457a8ec1674e81e2a46b496a9d217db8a61

Rename flymake--backend-state to flymake--state The previous name was confusing and akward and dreadful to type and read. * lisp/progmodes/flymake.el (flymake--state): Rename from flymake--backend-state. (flymake--with-backend-state): Use flymake--state. (flymake--handle-report): Use flymake--state. (flymake--collect): Use flymake--state. (flymake-running-backends): Use flymake--state. (flymake--disable-backend): Use flymake--state. (flymake--run-backend): Use flymake--state. (flymake-start): Use flymake--state. (flymake-mode): Use flymake--state. (flymake--mode-line-title): Use flymake--state. (flymake--mode-line-exception): Use flymake--state. (flymake--mode-line-counter): Use flymake--state.

view details

João Távora

commit sha 3f58587169450855cfa099226ae43b8b58d4c608

Refactor some Flymake functions * lisp/progmodes/flymake.el (flymake-diagnostic-buffer): New helper. (flymake-diagnostic-beg, flymake-diagnostic-end): Tweak docstring. (flymake--handle-report): Simplify. (flymake--publish-diagnostics): Helper for flymake--handle-report. (flymake--mode-line-counter, flymake-show-diagnostic) (flymake--diagnostics-buffer-entries): Use flymake-diagnostic-buffer, flymake-diagonstic-type, flymake-diagnostic-beg.

view details

João Távora

commit sha 1a0ab44425d1ea81f9671aa6601de109cec4a2e0

Unbreak M-x compile-defun of functions using flymake-log * lisp/progmodes/flymake.el (flymake-log): Check if compilation unit is indeed a string before treating it as a file name.

view details

João Távora

commit sha 9cbddcb622d956c32c636aa8d3b6dd3f06481d80

Abbreviate Flymake backend name in flymake-show-diagnostics-buffer * lisp/progmodes/flymake.el (flymake--diagnostics-buffer-entries): (flymake-diagnostics-buffer-mode): Report abbreviated backend, too.

view details

João Távora

commit sha 84ddf058f905e0de1ba8b72d62faa89541dc19a5

Keep and report "foreign" diangnostics in flymake-cc Flymake backend This includes diagnostics for .h files that sprang up when checking a c file. Those diagnostics are reported to the Flymake infrastructure which does not (yet) do anything with them. This includes a change to the test fixtures, too. * lisp/progmodes/flymake-cc.el (flymake-cc--make-diagnostics): Rework * test/lisp/progmodes/flymake-resources/another-problematic-file.c: New file. * test/lisp/progmodes/flymake-resources/some-problems.h: Add a function declaration..

view details

João Távora

commit sha da3715a62c3d23dbc0f363039ce326008d44ec37

Add support for project-wide diagnostics in Flymake This is done with two new concepts: "foreign diagnostics" and "list-only diagnostics". The manual has been updated with a description of these new concepts. * doc/misc/flymake.texi (Flymake utility functions): Explain creation of foreign diagnostics. (Foreign and list-only diagnostics): New subsection. * lisp/progmodes/flymake.el (flymake--highlight-line): Tweak docstring. Rework. (flymake--state): Add foreign-diags slot (flymake--clear-foreign-diags): New helper. (flymake--publish-diagnostics): Consider foreign diagnostics. Rework. (flymake-kill-buffer-hook): Clear foreign diagnostics (flymake--equal-diagnostic-p): New helper. (flymake-diagnostics): Tweak docstring. (flymake-mode): Consider other buffers' foreign diagnotics. (flymake--mode-line-counter): Use flymake-diagnosticsSummary: (flymake-list-only-diagnostics): New variable. (flymake--clear-list-only-diagnostics): New helper. (flymake-show-project-diagnostics): New command

view details

João Távora

commit sha 20c8a9ea1f3a9b47d90a0956167a7ca0e4863e6d

slightly less horrible

view details

João Távora

commit sha 6158e7e156204e4516b1ca8e72766903075cb741

still some work to go, but closer

view details

João Távora

commit sha 9002f646ffc4620f104b270fdbf617a8df98f108

getting there

view details

push time in 8 days

push eventjoaotavora/emacs

João Távora

commit sha 0bc7c92464c7bb282e662a198fcce63da7e0dec9

getting there

view details

push time in 8 days

create barnchjoaotavora/emacs

branch : scratch/bug-50244

created branch time in 8 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

(see the scratch/fido-in-region branch of the Emacs repo, if you want an early look into how it works)

jdtsmith

comment created time in 8 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

@astoff no. But is Consult a UI? Isn't it a table, or like, a collection of tables.To be clear what I'm working on, it's Emacs bug#45763 where a user complained that the existing variable icomplete-in-buffer isn't working correctly with fido-mode (it's not working very well with icomplete-mode either). So I'm attending to that bug.

jdtsmith

comment created time in 8 days

issue openederpalma/throttled

T480: Excuse my ignorance, but how do I tell if this is working (with s-tui)??

I've a T480 that presumably suffers from this problem:

 sudo dmidecode | grep 'BIOS Revision'
        BIOS Revision: 1.28

I'm also on Arch. I'm using

sudo systemctl start lenovo_fix.service

to enable and the corresponding stop to disable. I don't see any difference in s-tui graphs. I put s-tui into stress mode and see my CPU temps shoot to aroud 95 Celsius and the CPU freqs to around 3300Mhz then down to about 3050 Mhz. Exactly the same is I stop or start the service. What is going on: how does one see the throttling?

created time in 9 days

issue commentoantolin/orderless

Incompatible with the Python shell

In the category of "reading meaning into the overly-vague docs" @joaotavora counters with the doctoring of completion-at-point-functions (see this comment):

I haven't read this long thread, but if you mean the NOTE at the end of completion-at-point-functions, then I don't understand how it contradicts the rest of the docstring. I interpret it to say that (1) requesting a table table should be cheap which likely means a functional table and that (2) that table should ideally be composable with arbitrary completion styles. I.e. a big list of slow-to-calculate pre-filtered stuff should NOT be returned.

Now to the controversial bit, and the "doctoring": the table to be returned completes the entity between START and END. Note that this doesn't mean it's wrong to return a table that happens to be capable of completing other entities, like that other entity between START2 and END2, as long as it does the right thing for STARTandEND. But the docstring doesn't require it. The only requirement is that is the table must complete what's between START and END.

And this makes sense.to me: if someone (the user, via an UI) wants to complete something other than START and END, she can request it via another table, because, and this is where the NOTE becomes relevant, that request is "cheap to run".

Note that for Elisp in particular, which has a single big table of symbols, that table is super cheap to get and completes every "entity" possible in Elisp land, here and there, everywhere. So if a UI gets this table for Elisp -- it can be the obarray object unaltered -- it might use it everywhere and nothing bad ever happens. Same thing for simple lists of strings. But that UI must not make the mistake of thinking it's like that for every backend. For other backends that aren't as privileged as Elisp, the docstring must be followed more closely to get correct results.

In the end there are no miracles: these new fancy filtering completion styles must be implemented close to source of completions if they are to be fast and accurate, that is, since @jdtsmith seems to be OK with losing some accuracy by adjusting his "mental model" of what is happening.

Anyway for an example: SLY, a common Lisp IDE, actually implements prefix and flex directly in Common Lisp. A Python IDE would have to do the same, and maybe someday LSP will have provisions for this.

astoff

comment created time in 9 days

startederpalma/throttled

started time in 9 days

push eventjoaotavora/python-umonitor

João Távora

commit sha c20758884b8ee8445b176c6b30cfcb60ac87bf77

Got to fix this

view details

push time in 10 days

fork joaotavora/python-umonitor

Manage monitor configuration automatically.

fork in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

That comes with its own issues, like entirely defeating completion styles

We are going in circles: don't you remember that in LSP there can be no "real" completion styles? As for company, I think completion styles work there, even for company-capf, if the table doesn't override them that is.

Anyway, it's too much completionism for me today

jdtsmith

comment created time in 10 days

PR closed joaotavora/eglot

Invalidate the proxy cache when probe text is altered

This concerns the cache which eglot's collection table maintains as a lexical closure. Some completion UI's, like company, regenerate the collection table on new input. Others, like corfu, expect the backend to do the right thing based on the current text in the buffer, and keep the collection table alive during an entire completion process. Currently UI's with the latter behavior produce unexpected results when the original probe string is altered (see minad/corfu#59).

With this simple fix, if the initial "probe" text is ever altered or partially deleted, eglot will invalidate its cache and re-contact the LSP server.

+7 -0

14 comments

1 changed file

jdtsmith

pr closed time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

I'm closing this just for administrative reasons, but we can continue discussion or even reopen it later. Meanwhile, I'm working on a completion-in-region UI based on fido-vertical-mode that will, understandibly, not have these problems. It's a minibuffer-esque replacement for company.

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

But dear sir, how am I, a mere window offering but glimpses of the inscrutable depths of your knowledge, to know such trash from treasure?

lady, thou hath just received and conceded to a backspacing request from one of our users, surely that is sufficient to tell the difference

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

FYI, I just tested emacs-lisp completion via corfu, and the same collection table function indeed does the equivalent of serving fo when originally requested with foo. You may of course argue that this is an "accidental feature" or even a design flaw...

Yes. I guess that table has very fast means to get to the source of truth (i.e. it's in the same process) and so you that UI can abuse it. The completion UI's in Emacs core don't abuse it, as far as I know (but I may be mistaken).

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

Thanks, now I got it. So in my example should a collection table crafted for os.li serve for os.l as well?

No, it shouldn't.

She would fully agree with this logic. But she may further argue: it is your job Mr. Backend to address this insensibility.

Miss UI, it is you who is needlessly carrying that piece of garbage around, when I have this new one for you right here ready for your new state, should you need it

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

Yet a UI author may reasonably argue: as long as I keep a lambda alive and I'm querying it at the same point in the buffer, I expect it will keep itself up to date, by whatever means it decides.

"I'm querying it at the same point in the buffer". But is she? (she == the UI author). Indeed if at the same point (or with point within the bounds of the entity, to be more exacl) and in the same buffer state I 100% agree you can re-query the same table, perhaps to apply another style to it, a different predicate, dynamic variables, etc. But if you change the buffer, particularly if you delete some of the entity, than I don't think it makes any sense.

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

I do not at all think it's reasonable, for a completion UI to complet I don't see where the destruction of e comes in

I was talking about deleting the last o of foo which was where the table was first requested, to make it fo. I don't think the table for foo should serve for fo. Hope this is clear

jdtsmith

comment created time in 10 days

pull request commentjoaotavora/eglot

Invalidate the proxy cache when probe text is altered

I think this is clever but a solution that I wouldn't merge unless all other possibilities are exhausted. Here is the docstring of completion-at-point-functions:

Special hook to find the completion table for the entity at point.
Each function on this hook is called in turn without any argument and
should return either nil, meaning it is not applicable at point,
or a function of no arguments to perform completion (discouraged),
or a list of the form (START END COLLECTION . PROPS), where:
 START and END delimit the entity to complete and should include point,
 COLLECTION is the completion table to use to complete the entity, and
 PROPS is a property list for additional information.

As I wrote in #726, eglot-completion-at-point is written to this spec, not to some specific completion UI.

e-c-a-p returns a structure that delimits the entity to complete by START and END (an idea that, unfortunately, LSP doesn't have any means of respecting, but that's another problem). It also returns a way to get the collection of things to complete that entity, in COLLECTION. COLLECTION completes that entity delimited by START and END, call it e not some other entity e* that is derived from e.

(1) I think it's reasonably fair --though I wouldn't recommend it -- for a completion UI to experiment with filtering the results by adding new characters to e to build e*, but where e is contained in e, so that e wasn't changed. VSCode apparently does this to speed up filterings, by assuming that this addition can only mean a subset of candidates. Company-mode does not do this, neither do the vanilla completion method C-M-i. The reasons why I wouldn't recommend it are also explained in #726: in LSP, there's nothing telling me that adding a new character to the LSP document doesn't expand the set of viable completions at that point.

(2) I do not at all think it's reasonable, for a completion UI to completely destroy e into e* and to expect that the completion table that it received to complete e still serves to complete e*.

I short, I don't know understand why the completion UI can't re-request a table to complete the new entity. I think its fair to be able to configure a completion UI to do this fast explorative work if the user wants to sacrifice some accuracy for speed. But that manner of completion shouldn't be dictated by the completion table. Maybe in a completion style, at most.

jdtsmith

comment created time in 10 days

pull request commentrliou92/python-umonitor

Fix usage of '0' instead of '\x00'

This is very likely the same bug, yes (I believe you'll notice the byte that can't be decoded is different each run)

Indeed it is, and now I understand your fix. Also, it seems to sometimes work if it happens to find a \0 there, I guess. I ended up fixing it directly in the horribly long .c file. Since your fix was so simple, it wasn't that hard. Here's the diff:

diff --git a/umonitor/screen.c b/umonitor/screen.c
index ea9f9eb..03ca333 100644
--- a/umonitor/screen.c
+++ b/umonitor/screen.c
@@ -3700,7 +3700,7 @@ static char *__pyx_f_6screen_6Screen__get_output_name(CYTHON_UNUSED struct __pyx
  *             return output_name
  */
   __pyx_t_5 = __Pyx_PyIndex_AsSsize_t(__pyx_v_output_name_length); if (unlikely((__pyx_t_5 == (Py_ssize_t)-1) && PyErr_Occurred())) __PYX_ERR(0, 194, __pyx_L1_error)
-  (__pyx_v_output_name[__pyx_t_5]) = '0';
+  (__pyx_v_output_name[__pyx_t_5]) = 0;

   /* "screen.pyx":195
  *
@@ -4013,7 +4013,7 @@ static char *__pyx_f_6screen_6Screen__get_edid_name(struct __pyx_obj_6screen_Scr
  *
  *             # product = (edid[11] << 8) | edid[10];
  */
-  (__pyx_v_vendor[3]) = '0';
+  (__pyx_v_vendor[3]) = 0;

   /* "screen.pyx":240
  *             # snprintf(edid_info, length, "%04X%04X%08X", vendor, product, serial);
GPery

comment created time in 11 days

pull request commentrliou92/python-umonitor

Fix usage of '0' instead of '\x00'

This is very likely the same bug, yes (I believe you'll notice the byte that can't be decoded is different each run)

Indeed it is, and now I understand your fix. Also, it seems to sometimes work if it happens to find a \0 there, I guess

GPery

comment created time in 11 days

pull request commentrliou92/python-umonitor

Fix usage of '0' instead of '\x00'

Right, regenerate the .c file from the pyx file. Any hints on how I can do that manually?

GPery

comment created time in 11 days

pull request commentrliou92/python-umonitor

Fix usage of '0' instead of '\x00'

@GPery was the "problem" you had similar to this one?``` ❯ umonitor -l docked-with-the-big-one Traceback (most recent call last): File "/usr/bin/umonitor", line 33, in <module> sys.exit(load_entry_point('umonitor==20181018', 'console_scripts', 'umonitor')()) File "/usr/lib/python3.9/site-packages/umonitor-20181018-py3.9-linux-x86_64.egg/umonitor/init.py", line 23, in main umon.run() File "/usr/lib/python3.9/site-packages/umonitor-20181018-py3.9-linux-x86_64.egg/umonitor/umonitor.py", line 36, in run self.load_profile() File "/usr/lib/python3.9/site-packages/umonitor-20181018-py3.9-linux-x86_64.egg/umonitor/umonitor.py", line 112, in load_profile self.setup_info = self.get_setup_info() File "umonitor/screen.pyx", line 417, in screen.Screen.get_setup_info File "umonitor/screen.pyx", line 106, in screen.Screen._get_output_info UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 4: invalid start byte


?
GPery

comment created time in 11 days