On Tue, Dec 31, 2013 at 3:05 PM, Dmitry Gutov <
raa...@gmail.com> wrote:
> On 31.12.2013 16:31, João Távora wrote:
>>
>> (setcdr yas-snippet-dirs (cons my-dir (rest yas-snippet-dirs)))
>>
>> does what the OP requested: add to the second place in a list. Its a
>> one-liner and works with every list I know.
> Like mentioned, it doesn't handle all possible values.
Fair enough, see my reply.
>> It also doesn't try to hide the weirdness. I've already agreed that the
>> polymorphic is weird. Try writing a docstring for the `yas-add-to-dirs'
>> originally provided by the OP.
> The docstring wouldn't describe the exact manipulation of the value. It
> would say something like "adds a new location to use snippets from".
>> I am convinced that less is more. Providing less of an
> The sentence is cut short here.
Sorry. I was going to write "providing less interface is less prone to error".
>>> If every package has to implement this logic to integrate with Yasnippet,
>>> it would be better if Yasnippet itself included such a function.
>>
>>
>> I'm not sure I understand the logic, but read below. Packages should
>> leave yas-snippet-dirs untouched. It's a user customization variable! It
>> should be set where yasnippet is setup.
>
>
> We allow the user to explicitly use our snippet directory. If they don't,
> the variable is left untouched.
>
> Asking the user to customize it manually is unrealistic. The path to our
> snippets directory is
> "/home/gutov/.emacs.d/elpa/yasnippet-YYYYMMDD.XYZ/snippets": it changes with
> each package update.
But I meant the rspec-mode/snippets directory. That's the directory
that you should
recommend that users add to the end (or to the second position) of
yas-snippet dirs.
And, as you know, you can abbreviate /home/gutov with ~. And I'm
pretty sure emacs
also provides a variable that takes you directory to ~/.emacs.d/elpa.
Consistently
finding the rspec-mode snippet dir from there should be easy. A short
enough snippet
should provide that.
And I even think, rspec mode could provide a variable that points
directly to its snippet
directory. And that variable can be set in rspec-autoloads.el or something.
This is my preferred alternative.
>>> Since rspec-mode is autoloaded, we can't really recommend calling that
>>> function before the user calls `yas-global-mode', which happens
>>> somewhere in the init file.
>> I don't think it has anything to do with autoloads.
> It has everything to do with autoloads because `rspec-install-snippets' is
> in `rspec-mode.el', which is autoloaded. Calling it would force the loading
> of the package.
But I never stated that you should call that function. I stated the opposite.
>> 2) If you want your rspec-snippets to be active by default for all
>> yasnippet users then I'm afraid you have to call `yas-load-directory'
>> in your major-mode's hook.
> Wouldn't it have to make the same work each time rspec-mode is enabled, as
> opposed to only loading the directory once?
It could well detect that it has performed that work already, by using
a global variable.
The only problem would be that a yas-reload-call wouldn't set that
variable to nil again.
But, yes, in my opinion that is replicating work already done by the
jit-loading logic.
That is why I added 1) as a preferred alternative to 2).
>> It would have to be conditionalized to ... some logic that detects if
>> `yas-reload-all' has happened in the meantime.
> Not sure if I follow. Why?
Because if you call load-directory in the major-mode hook, then an interactive
call to yas-reload-all will clear the snippets thus loaded and reload everything
fresh from yas-snippet-dirs. Therefore, a user working in a rspec-mode buffer
will loose his rspec mode snippets.
>> 3) Lastly if you really want to mess with `yas-snippet-dirs' in
>> `rspec-install-snippets', use
>>
>> (when (listp yas-snippet-dirs)
>> (add-to-list 'yas-snippet-dirs dir 'append))
>>
>> It's two lines and quite readable. It won't work if it's an atom, but
>> then you shouldn't touch it if it is.
> Why? In that case the value's just equivalent to a list with that value
> inside. Where does it say that it's otherwise special?
Because if it's an atom probably the the user wants a single snippets directory
and noone messing with it.
>> Not to mention you shouldn't
>> touch a user customization variables.
> There's nothing wrong in providing a convenience function that modifies a
> `defcustom' value. Using that macro only means that the user should be able
> to modify the variable using Customize interface, not that it's untouchable.
> Take a look at the definition of `find-file-hook', for example.
Fair enough.
>> BTW what specific eval-after-load hook are you talking about? rspec-mode
>> or yasnippet's?
> rspec-mode's. Have you looked at its README? It's right there under
> Installation:
https://github.com/pezra/rspec-mode/
I have. I see you're using add-to-list in your "install-snippets". Is that not
working? I stated before I don't consider that the best option, but if it works
for you...
> Okay, I'll rephrase that: just like it's common to have variables with
> complex values, it's common to provide accessors for them. An easy example
> is `defstruct' and accessor functions it generates. For something different,
> see code different code examples in SICP.
The reason defstruct defines accessors is for hiding its implementation, which
is commonly based on arrays, but need not be as per hyperspec at least I think.
It's not for convenience. Lists in lisp are fundamental
data-structures and that's a
fundamental difference. They come with a whole dictionary of manipulators.
Doesn't mean you cant add to it, but it just doesn't make sense to me
in this case.
> The latter doesn't have much to do with Emacs, so it's not the best possible
> example, sorry. But yours are not better:
I disagree. The examples of complex datastructures which are modified
by using list manipulators. Arguably comment-use-syntax isn't a good
one, I just took
the first hit. But the minibuffer completion table, or any other
table, is something you
add to using push and add-to-list. I might want to add to its existing
value, why not?
If I need to do that, I'll have to check its type. But maybe there's a
reason that it isn't
easy, maybe it's not meant to be added to like that. Just like
yas-snippet-dirs. I designed
it to be set by users, not packages, and you should try to adhere to
that and not fight it.
I didn't look and really don't have time to. But I suspect there are many
"atom or list" variables that don't come with specialized accessors.
Lastly, worry not, because I plan to drop compatibility for the single
string value in
yas-snippet-dirs. I am also redesigning the snippet expansion engine
in conjunction
with stefan and we hope it will have a nice programmatic approach to
defining snippets
as macros. Have a look in the snippet-engine branch.