yaml.el icon indicating copy to clipboard operation
yaml.el copied to clipboard

:object-type 'alist as a default

Open conao3 opened this issue 4 years ago • 3 comments

Thanks for such a great package! I try this package, this parser works like a charm.

One point I notice, please output as a alist instead of hash-table?

Hash tables have their advantages when accessing large objects, but when it comes to user-friendly output and access methods, Elisp is more comfortable with alist and plist data formats. Let's try to display the nested hash table in a scratch buffer. It's not very readable.

(yaml-parse-string "
uri: https://www.google.co.jp
user: foo
password:
  a:
    b:
      - c
      - d  
")
;;=> #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
;;                 ("password" #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
;;                                           ("a"
;;                                            #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
;;                                                          ("b" ["c" "d"]))))
;;                  "user" "foo"
;;                  "uri" "https://www.google.co.jp"))

Access to the hash table is not provided in a very convenient way from Emacs native. I also want use ht to access hash-table. I would suggest that the default behavior is to convert with alist. If a user wants to load a very large yaml with more than 1000 lines, it would be very desirable to have the option to output as a hash table.

conao3 avatar Apr 13 '21 10:04 conao3

Hi, thanks for opening these issues! I agree with the points you brought up that alists and lists rather than hash-maps and vectors are more commonly used. A main guiding principle in this library though is to match the API of the JSON parsing functions like json-parse-string which for some reason they choose to default to hash-maps and vectors. The ticket you brought up about symbol keys (#13) is actually a difference from the JSON API as well and should be fixed in any case.

I'd definitely be open to discussing the pros and cons of trying to match the json-parse API as close as possible vs. defaulting to more commonplace lisp data structures.

zkry avatar Apr 14 '21 05:04 zkry

Yes, I know json package. You reference its API? I got it. How about yaml-object-type variable like json-object-type?

conao3 avatar Apr 14 '21 13:04 conao3

Yeah! These types of variables would be a great addition. I'll create a ticket for this.

zkry avatar Apr 15 '21 03:04 zkry