Citeproc error after updating to debian buster - void variable bibtex completion display formats - emacs

I am able to insert article citations in org mode using org-cite-insert but when i try to export it to html i get the following error. It worked beautifully a day ago but is acting up after i basically powerwashed my chromebook to install debian buster. Would really appreciate any advice.
Thanks.
Debugger entered--Lisp error: (void-variable bibtex-completion-display-formats)
byte-code("\306 \210\307\10\310\11!\n#\210\311\303\312\313\314DD\315\316\317\320\321&\7\210\322\13G\13\323\3\3X\203G\0\1:\203G\0\1#\262\1\324\1#\f..." [org-mode-map org-ref-insert-cite-key org-ref-insert-link-function org-ref-bibtex-completion-actions helm-source-bibtex bibtex-completion-format-citation-functions org-ref-bibtex-completion-completion define-key kbd custom-declare-variable funcall function #f(compiled-function () #<bytecode 0x1f400016fe914>) "Cons cells of string and function to set the actio..." :type (alist :key-type (string) :value-type (function)) :group org-ref 0 nil helm-delete-action-from-source helm-add-action-to-source org-ref-bibtex-completion-format-org #f(compiled-function () #<bytecode 0x1f4010b9da114>) "Function for how `helm-bibtex' inserts citations." org-mode org-ref-helm-insert-cite-link org-ref-cite-click-helm org-ref-bibtex-completion-add-keywords-field #f(compiled-function () #<bytecode 0x1f400016fe5d4>) "Whether to add the `keywords' field to bibtex-comp..." boolean keywords "keywords" alist-get t "{keywords:" string-match " ${keywords:31}" org-ref-insert-cite-function org-ref-cite-onclick-function bibtex-completion-additional-search-fields bibtex-completion-display-formats inhibit-changing-match-data] 8)
require(org-ref-helm-bibtex)
eval-buffer(#<buffer *load*-422164> nil "/home/pixel/.emacs.d/elpa/org-ref-2.0.0/org-r..." nil t) ; Reading at buffer position 1644
load-with-code-conversion("/home/pixel/.emacs.d/elpa/org-ref-2.0.0/org-r..." "/home/pixel/.emacs.d/elpa/org-ref-2.0.0/org-r..." nil t)
require(org-ref)
eval-buffer(#<buffer *load*> nil "/home/pixel/.emacs.d/elpa/citeproc-org-0.2.4/..." nil t) ; Reading at buffer position 1539
load-with-code-conversion("/home/pixel/.emacs.d/elpa/citeproc-org-0.2.4/..." "/home/arcotpixel/.emacs.d/elpa/citeproc-org-0.2.4/..." nil t)
citeproc-org-render-references(html)
run-hook-with-args(citeproc-org-render-references html)
org-export-as(html nil nil nil (:output-file "article.html"))
org-export-to-file(html "article.html" nil nil nil nil nil)
org-html-export-to-html(nil nil nil nil)
org-export-dispatch(nil)
funcall-interactively(org-export-dispatch nil)
call-interactively(org-export-dispatch nil nil)
command-execute(org-export-dispatch)

Related

query is returning "expected 0 arguments, got 1"

I am trying to query a database that I know has data in it from directly querying within pgadmin. When I query using the following code it returns no results:
const DATABATE_URL = "postgres://postgres:pw#localhost:5432/postgresdb"
conn, err := pgx.Connect(context.Background(), DATABATE_URL)
defer conn.Close(context.Background())
if err != nil {
fmt.Printf("Connection failed: %v\n", err)
os.Exit(-1)
}
stmt := "SELECT * FROM nodes"
rows, err := conn.Query(context.Background(), stmt, nil)
if err != nil {
fmt.Fprintf(os.Stderr, "QueryRow failed: %v\n", err) //error outs here "expected 0 arguments, got 1"
os.Exit(1)
}
for rows.Next() {
var results string
err = rows.Scan(&results)
if err != nil {
fmt.Fprintf(os.Stderr, "QueryRow failed: %v\n %n", err)
os.Exit(1)
}
fmt.Println(results)
}
When I directly connect to the database through goland and pgadmin and query with the same statement I can see all the data. What am I missing here?
The pgx Conn.Query accepts a context, statement and arguments:
func (c *Conn) Query(ctx context.Context, sql string, args ...interface{}) (Rows, error)
You are passing it a context, statement and nil:
rows, err := conn.Query(context.Background(), stmt, nil)
So the nil is treated as an argument but your SQL statement does not contain any argument placeholders (e.g. SELECT * FROM nodes where id=$1) hence the error. To fix this run:
rows, err := conn.Query(context.Background(), stmt)
However it would also be worth editing your sql to specify the column you want (e.g. SELECT nodename FROM nodes).
Note: When raising a question like this please include the error in the question body rather than just as a comment in the code (which is easy to miss).

Emacs `dired` error when renaming file using Helm: `apply` wrong number of arguments

I don't use dired mode too often, but was trying to practice with it a bit. So I created a few empty practice text files and marked them with the usual dired shortcut key. Then I tried to rename the files using the "R" command--in order to move the files to a new folder. I get this odd error and the operation does not succeed.
apply: Wrong number of arguments: (8 . 8), 10 [3 times]
I ran into the same error when I tried to do a copy using the "C" command. But interestingly enough, the problem does not occur when I tried to do a delete with "D". Delete did work. So it seems like somewhere the apply function is being used incorrectly.
I am using emacs version 25.3 and Spacemacs version 0.200.13.x on ubuntu linux 16.04 LTS.
Does anyone have a sense of why this error is occurring? Since dired is part of the emacs core, I imagine there might be some conflict with a different package or something. I checked the spacemacs github repo issues list, but did not see any problems mentioned. Any help would be appreciated.
UPDATED
As per Phil's suggestion, here is the stacktrace:
Debugger entered--Lisp error: (wrong-number-of-arguments (8 . 8) 10)
helm-read-file-name-handler-1("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil "dired-do-rename" "*helm-mode-dired-do-rename*")
apply(helm-read-file-name-handler-1 ("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil "dired-do-rename" "*helm-mode-dired-do-rename*"))
helm--completing-read-default("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil)
apply(helm--completing-read-default ("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil))
#f(advice-wrapper :override completing-read-default helm--completing-read-default)("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil nil)
completing-read("Rename jarrett-iccv-09.pdf to: " read-file-name-internal file-exists-p nil "~/Downloads/" file-name-history nil)
read-file-name-default("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
ido-read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
apply(ido-read-file-name ("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil))
#f(advice-wrapper :override #f(advice-wrapper :override read-file-name-default helm--generic-read-file-name) ido-read-file-name)("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil nil nil nil)
read-file-name("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil)
apply(read-file-name ("Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil))
dired-mark-pop-up(nil move ("jarrett-iccv-09.pdf") read-file-name "Rename jarrett-iccv-09.pdf to: " "/home/krishnab/Downloads/" nil)
dired-mark-read-file-name("Rename %s to: " "/home/krishnab/Downloads/" move nil ("jarrett-iccv-09.pdf") nil)
dired-do-create-files(move dired-rename-file "Move" nil t "Rename")
dired-do-rename(nil)
funcall-interactively(dired-do-rename nil)
call-interactively(dired-do-rename nil nil)
command-execute(dired-do-rename)
UPDATED 2
There does seem to be a similar issue reported under the helm github repository. Seems that helm and ido mode are not compatible.
https://github.com/emacs-helm/helm/issues/1819
There is also a reference to this in the helm wiki.
https://github.com/emacs-helm/helm/wiki#use-helm-mode-and-ido-mode
I tried some of their suggestions, like adding
'(helm-completing-read-handlers-alist
(quote
((find-file-read-only . ido)
(find-alternate-file . nil))
But still getting the same error.
At first glance, this looks to me like a bug in the current version of helm.
Installing helm from MELPA, I see that helm-read-file-name-handler-1 accepts 8 arguments:
(helm-read-file-name-handler-1 PROMPT DIR DEFAULT-FILENAME MUSTMATCH INITIAL PREDICATE NAME BUFFER)
While helm--completing-read-default is guaranteed to call it with 10, as per the stack trace.
helm--completing-read-default looks up dired-do-rename in helm-completing-read-handlers-alist and finds that it is mapped to helm-read-file-name-handler-1. It then recognises the handler as being name-spaced as a helm function and, on that basis, calls it with 2 additional helm-specific arguments.
By default, helm-completing-read-handlers-alist includes:
(dired-do-rename . helm-read-file-name-handler-1)
(dired-do-copy . helm-read-file-name-handler-1)
(dired-do-symlink . helm-read-file-name-handler-1)
(dired-do-relsymlink . helm-read-file-name-handler-1)
(dired-do-hardlink . helm-read-file-name-handler-1))
So this issue affects all of those dired commands.
You could presuambly work around this by removing all of those.
e.g. M-x customize-option RET helm-completing-read-handlers-alist

getting "unexpectedly found nil" AFTER performing nil check

Despite checking for nil, I am getting fatal error: unexpectedly found nil while unwrapping an Optional value the error is being caught in the conditional (first line below)
if (obj.prop != nil && obj.prop?.otherprop != nil) {
anotherObj.yetanotherprop = (obj.prop?.otherprop as NSURL).absoluteString
}
I have also tried this with if let as follows (xcode highlights the 2nd let as being where the unexpected nil is found):
if let objA = obj.prop,
let otherProp = objA.otherPROP {
anotherObj.yetanotherprop = (otherProp as NSURL).absoluteString
}
Why don't either of these work?!
I am getting the source object (obj in both cases above) from a 3rd party library that is written in objective c. I am suspecting that I am checking for nil wrong somehow?
So in writing this up I think I sort of figured it out. I don't knwo why the first one doesn't work, but the second works as:
if let objA = obj.prop,
let otherProp = objA?.otherPROP {
anotherObj.yetanotherprop = (otherProp as NSURL).absoluteString
}

Difference between error = error vs error != nil

I would like to know is there big difference between
if let error = error{} vs if error != nil? Or is it just how people are different, like how they express themselves in code?
For example if I take this code:
user?.delete { error in
if let error = error {
print(error)
} else {
}
Because I can do the same like this and the output is the same:
user?.delete { error in
if error != nil {
print(error)
}else{
}
The only difference I can see other than "people are different" is that if I do not print error it would be better to use if error != nil because otherwise it would be declaring variable you do not use. Am I right?
As you already recognized at the end of your question, I would agree with you, that I would use if let, if I want to use the error variable to print it out for example. If I would just check if it's not nil and don't need the error variable, I would use if error != nil. You could also do if let _ = error, which is the same as if error != nil as Eric Aya mentioned in the comments of your question

How to encode/decode a empty string

I am using the GOB encoding for my project and i figured out (after a long fight) that empty strings are not encoded/decoded correctly. In my code i use a errormessage (string) to report any problems, this errormessage is most of the time empty. If i encode a empty string, it become nothing, and this gives me a problem with decoding. I don't want to alter the encoding/decoding because these parts are used the most.
How can i tell Go how to encode/decode empty strings?
Example:
Playground working code.
Playground not working code.
The problem isn't the encoding/gob module, but instead the custom MarshalBinary/UnmarshalBinary methods you've declared for Msg, which can't correctly round trip an empty string. There are two ways you could go here:
Get rid of the MarshalBinary/UnmarshalBinary methods and rely on GOB's default encoding for structures. This change alone wont' be enough because the fields of the structure aren't exported. If you're happy to export the fields then this is the simplest option: https://play.golang.org/p/rwzxTtaIh2
Use an encoding that can correctly round trip empty strings. One simple option would be to use GOB itself to encode the struct fields:
func (m Msg) MarshalBinary() ([]byte, error) {
var b bytes.Buffer
enc := gob.NewEncoder(&b)
if err := enc.Encode(m.x); err != nil {
return nil, err
}
if err := enc.Encode(m.y); err != nil {
return nil, err
}
if err := enc.Encode(m.z); err != nil {
return nil, err
}
return b.Bytes(), nil
}
// UnmarshalBinary modifies the receiver so it must take a pointer receiver.
func (m *Msg) UnmarshalBinary(data []byte) error {
dec := gob.NewDecoder(bytes.NewBuffer(data))
if err := dec.Decode(&m.x); err != nil {
return err
}
if err := dec.Decode(&m.y); err != nil {
return err
}
return dec.Decode(&m.z)
}
You can experiment with this example here: https://play.golang.org/p/oNXgt88FtK
The first option is obviously easier, but the second might be useful if your real example is a little more complex. Be careful with custom encoders though: GOB includes a few features that are intended to detect incompatibilities (e.g. if you add a field to a struct and try to decode old data), which are missing from this custom encoding.