Cider: CIDER não mostra documentos para Java

Como você pode ver, o símbolo também foi resolvido por engano para java.lang.Character / toUpperCase em vez de lang.String.

Você não recebe um prompt perguntando qual versão escolher?

@bbatsov Estranhamente, hoje é assim (que é muito melhor 😂):

Eu verifiquei e recebo o prompt quando uso a tecla de atalho padrão (no Spacemacs é , h h no estado normal-mal), mas não quando uso esta tecla de atalho que configurei:

(key-chord-define-global "fd" '(lambda () (interactive "")
                                   (cond
                                    ((or (eq evil-state 'normal) (eq evil-state 'visual)) (execute-kbd-macro (kbd "<escape> , h h")))
                                    ((eq evil-state 'insert) (execute-kbd-macro(kbd "<escape> l , h h i"))))))

Esta tecla de atalho de alguma forma pula o prompt e mostra apenas os documentos para o personagem.

BTW, a dica do eldoc também poderia usar algum trabalho, por exemplo, uma separação entre os argumentos dos diferentes métodos:

Não conseguimos descobrir uma boa separação, é por isso que apenas misturamos as assinaturas de todas as versões possíveis. É ideal, mas infelizmente também não consigo ver como isso pode ser melhorado. O Eldoc deve ter uma estrutura ver string, caso contrário, o destaque dos parâmetros lá iria quebrar.

@bbatsov Acabei de reiniciar meu Emacs e os Javadocs desapareceram novamente. :(

Eu me pergunto se as coisas mudam para você se você tentar o Java 8 em vez de 9. Não tive muito tempo para brincar com o Java 9 e me pergunto se parte da manipulação de classpath que fazemos não está funcionando corretamente ou algo assim. Além disso, certifique-se de que o buffer de código foi avaliado antes de tentar eldoc / cider-doc).

@bbatsov Eu mudei para o Java 8 e ainda não tive nenhum problema (mas não fiz muita codificação desde então, quem sabe).
E eu acabei de entender que você é a pessoa que está dando aquela palestra ^ __ ^ De alguma forma seu avatar parecia tão agressivo para mim e isso me surpreendeu :)) Obrigado pelo seu trabalho;) Estou assistindo a sua palestra sobre Clojure Bad Parts agora 😊

Haha!

E eu pensei que essa era a minha cara feliz! 😄

Olá, (emacs / iniciante de cidra aqui)

Onde na cidra / ROADMAP geral esse bug está posicionado?

É mais

• ninguém tem tempo para trabalhar nisso
• será resolvido com / por pomar
• funciona como pretendido
• não deveria funcionar agora?

Toda vez que passo algum tempo aprendendo clj / emacs, acabo querendo pesquisar alguma aula e fico frustrado - o que é inteiramente por minha conta, mas fico me perguntando:

Minha configuração está errada ou quebrada, ou os devs de clojure "reais" nunca precisam procurar um javadoc - o que seria bastante desconcertante para mim.

Meu caso de teste é pesquisar por meio de cider-doc java.util.concurrent.PriorityBlockingQueue que resulta em https://imgur.com/a/TaQXfpS .

Resumindo: isso é quebrado apenas para mim ou para todos e como as pessoas lidam com isso?

PPS: tentei com java 8-11 com java-doc e java-src instalados

Saídas:

em uma aula

java.util.concurrent.PriorityBlockingQueue
   Extends: java.util.AbstractQueue
Implements: java.util.concurrent.BlockingQueue
            java.io.Serializable

Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

em um método

java.util.concurrent.PriorityBlockingQueue/add
 [this java.lang.Object]
Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

Progresso !

Eu acho que o seguinte está acontecendo

Premissa: eu uso spacemacs, que usa cidra da MELPA, atualmente 0,20,0 + cidra-nrepl 0,20,0

cidra-nrepl 0.20.0 usa pomar 0.3.1

Edição:

orchard detecta fontes java por meio de jdk-sources -> jdk-resource-url e criticamente -> jdk-root

(def jdk-root
  "The JDK root directory (parent of the `java.home` JRE directory)"
  (-> (io/file (System/getProperty "java.home"))
      (.getParentFile)))

(https://github.com/clojure-emacs/orchard/blob/v0.3.1/src/orchard/java.clj#L47)

No meu sistema (archlinux) e no pacote ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 , parece que os javas estão dispostos como pastas em /usr/lib/jvm

ie

# ~/Downloads/openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64/data $ tree usr/lib/jvm/ -L 2
usr/lib/jvm/
├── java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
└── java-11-openjdk-amd64

ou archlinux

# ~ $ tree /usr/lib/jvm/ -L 2
/usr/lib/jvm/
├── default -> java-11-openjdk
├── default-runtime -> java-11-openjdk
├── java-11-openjdk
├── java-8-openjdk
└── java-default-runtime -> default

em uma demonstração emacs / cider repl java.home é isto é:

(System/getProperty "java.home") 
; =>  /usr/lib/jvm/java-11-openjdk

_Eu não sei se algo de fora passa isso, ou se é a casa padrão atual do java._

se não me engano, isso significaria que no meu sistema a raiz jdk é

(-> (io/file (System/getProperty "java.home"))
      (.getParentFile))) 
; => /usr/lib/jvm/

resultando em jdk-resource-url procurando coisas na pasta errada (pai)

Conclusão:

jdk-roots "O comentário / premissa do diretório raiz JDK (pai do diretório java.home JRE)" parece estar errado (eu rapidamente verifiquei online e parece não haver um "padrão" como o que java. casa realmente é para ser)

Isso ajuda alguém?

Sim, ajuda! Por meio do java 8, a propriedade de sistema java.home aponta para um JRE na raiz do JDK. Isso é esperado por https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html. Não consigo encontrar um link para javase / 8, mas observe empiricamente (no Debian):

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-8-openjdk-amd64/jre"

Do java 9 em diante, o subdiretório JRE desapareceu e seu conteúdo foi mesclado um nível acima na raiz JDK, que java.home agora aponta para:

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-11-openjdk-amd64"

(consulte https://docs.oracle.com/en/java/javase/11/install/installed-directory-structure-jdk.html)

Como um aparte para usuários de distros derivadas do Debian, o pacote openjdk-11-source instala um link simbólico quebrado para src.zip (veja https://bugs.launchpad.net/ubuntu/+source/openjdk-lts / + bug / 1791219)
Depois de instalá-lo, tenho:

$ pwd
/usr/lib/jvm
$ ls -l java-11-openjdk-amd64/src.zip
lrwxrwxrwx 1 root root 21 Nov 20 04:13 java-11-openjdk-amd64/src.zip -> ../openjdk-11/src.zip
$ find openjdk-11 -type f
openjdk-11/lib/src.zip

Parece que o pomar deve verificar em ambos os lugares e testar se src.zip está legível. Também seria bom imprimir um aviso que pode ser silenciado para STDERR, caso contrário.
Eu ficaria feliz em enviar um PR, se isso parecer razoável.

Enquanto isso, você pode encontrar sua cópia de src.zip e adicioná-la ao classpath manualmente, por exemplo, usando uma entrada :local/root deps.edn (se você estiver em tools.deps https: / /clojure.org/reference/deps_and_cli#_dependencies).

hm, parece que a cadeia de chamadas jdk-sources -> jdk-root só é chamada quando no boot-class-loader, caso contrário, é (.getContextClassLoader (Thread/currentThread)) ,

Forcei o zip no caminho de classe por meio de project.clj

:profiles {:repl {:resource-paths ["/usr/lib/jvm/default/lib/src.zip"]}}

e verificado via

> (System/getProperty "java.class.path") ; in repl buffer
; "/home/_/Projekte/repos/temp/test/test:/_/patrik/Projekte/repos/temp/test/src:
   /usr/lib/jvm/default/lib/src.zip:  <snip>

ainda sem doc

Parece que isso não funcionará no Java 11 até que https://github.com/clojure-emacs/orchard/issues/20 seja corrigido.
Porém, o Java 8 deve funcionar. Você precisará de src.zip e tools.jar no caminho de classe, que deve ser adicionado automaticamente. Então você pode tentar algo como o seguinte (na cidra v0.21.1):

(clojure.java.io/resource "java/util/AbstractQueue.java")
;; => #object[java.net.URL 0x2e00bc76 "jar:file:/usr/lib/jvm/java-8-openjdk-amd64/src.zip!/java/util/AbstractQueue.java"]

(require '[mranderson049.orchard.v0v4v0.orchard.java.parser :as ojp])

(keys (ojp/source-info 'java.util.AbstractQueue))
;; => (:class :doc :line :column :members :file :path)

Este problema foi automaticamente marcado como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado pela sua contribuição e compreensão!

@jeffvalk recentemente abordou o problema do Orchard vinculado, então acho que podemos fechar este aqui.

No Debian 10, tudo que tive que fazer foi instalar openjdk-11-source . Fui tentar criar um link simbólico src.zip e descobri que ele já havia sido criado.

No Ubuntu 18.04 com Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 adicionei um dir contendo um zip com fontes Java como um recurso para o perfil Leiningen ( ~/.lein/profiles.clj ):

{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}