flycheck-haskell-process-configuration should setq not append options

[flycheck]

flycheck-haskell-process-configuration should setq not append options

[swsnr]

@gracjan I disagree. Closing as “wontfix”, for this is a feature, not a bug.

The GHC settings are empty by default, so normally Flycheck will only use the Cabal settings. But if they aren't empty, i.e. if the user explicitly added additional settings, changes are, that the user really wants to use these additional settings, for whatever reason, and we should never ignore or overwrite explicit settings made by the user.

And again, this is not Cabal, and I do not intend to mimic Cabal as closely as possible. That is way to complicated, and essentially just a duplication of what cabal build already does. Hence, #8. That's the way to go, not making this extension more and more complicated by putting more and more cabal settings into it. That's not going to happen.

[swsnr]

@gracjan The user package database flag is still there, but it's only set if building inside a sandbox.

[gracjan]

Running (flycheck-haskell-configure) twice appends all the flags twice.

At least make it append to the defaults not to current buffer local values.

Also my project disagrees with you. It flychecks perfectly when running
with options set, does not flycheck when using some inconsistent mash up of
flags sourced from here and there.

2014-06-04 11:20 GMT+02:00 Sebastian Wiesner [email protected]:

@gracjan https://github.com/gracjan The user package database flag is
still there, but it's only set if building inside a sandbox.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[swsnr]

@gracjan GHC options don't appear magically from outer space. If you have additional GHC options, that did not come from this extension, then it's only because you explicitly added these options somewhere, e.g. in your init.el or via local variables.

Duplicating flags won't do no harm. I agree, though, that we need to remove old values in flycheck-haskell-configure. But that's a separate issue.

[gracjan]

flycheck-ghc-xxxx serve a very nice purpose when flychecking Haskell source
files that are not part of cabal project. In case of flychecking source
files under cabal project they cause issues.

Example:

Global package db set in flycheck-ghc-package-db to ("~/my-package-db")
contains package called "monads-tf-1.2.3".

Cabal project explicitly asks to use only local sandbox packages. Local
sandbox contains "monads-tf-4.5.6".

Since local sandbox is appended to package db list then packages will be
picked from global package db defined in global flycheck-ghc-options.

Conflict! No compilation.

2014-06-04 11:36 GMT+02:00 Sebastian Wiesner [email protected]:

@gracjan https://github.com/gracjan GHC options don't appear magically
from outer space. If you have additional GHC options, that did not come
from this extension, then it's only because you explicitly added these
options somewhere, e.g. in your init.el or via local variables.

Duplicating flags won't do no harm. I agree, though, that we need to
remove old values in flycheck-haskell-configure. But that's a separate
issue.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[swsnr]

@gracjan That's a configuration error. You should not set flycheck-ghc-package-db globally.

[gracjan]

Yyyy?

M-x customize flycheck-ghc-package-databases

?

What's not global about this?

Also: flycheck-ghc-package-databases was an example. All other options
cause very similar issues.

2014-06-04 12:51 GMT+02:00 Sebastian Wiesner [email protected]:

@gracjan https://github.com/gracjan That's a configuration error. You
should not set flycheck-ghc-package-db globally.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[swsnr]

@gracjan M-x customize sets variables globally. These should affect all buffers. That is the standard semantics of M-x customize, and that is what most users will expect. No package should programatically overwrite these settings.

If you don't want that, don't use M-x customize to set Flycheck's variables. They are buffer-local for a reason: Use a hook to set them for some buffers only, or use file- or dir-local variables to set them just from some files or projects respectively. That is, what Flycheck recommends you to do:

[…] Options are mainly intended to be used […] via File or Directory Local variables. See File Variables(emacs) and Directory Variables(emacs) respectively.

In other words, you should not change these options via M-x customize (or with setq-default), unless you really want to have them in all buffers. In this case, you obviously don't want it, so don't use M-x customize.

[gracjan]

I did not know about file-local or directory-local variables.

My point still stands: flycheck-haskell-configure should append to
original values of variables, not cumulative append as it does now.

I have no idea where to get original value once it has been set by
flycheck-haskell-configure.

2014-06-04 16:01 GMT+02:00 Sebastian Wiesner [email protected]:

@gracjan https://github.com/gracjan M-x customize sets variables
globally. These should affect all buffers. That is the standard
semantics of M-x customize, and that is what most users will expect. No
package should programatically overwrite these settings.

If you don't want that, don't use M-x customize to set Flycheck's
variables. They are buffer-local for a reason: Use a hook to set them for
some buffers only, or use file- or dir-local variables to set them just
from some files or projects respectively. That is, what Flycheck recommends
you to do
http://flycheck.readthedocs.org/en/latest/guide/usage.html#syntax-checker-options
:

[…] Options are mainly intended to be used […] via File or Directory
Local variables. See File Variables(emacs) and Directory Variables(emacs)
respectively.

In other words, you should not change these options via M-x customize (or
with setq-default), unless you really want to have them in all buffers.
In this case, you obviously don't want it, so don't use M-x customize.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[swsnr]

Well, local variables are an essential part of Emacs, especially Directory Local Variables. They provide a convenient and simple way to have project-specific settings.

[swsnr]

As for flycheck-haskell-configure, I agree that it should be fixed. Could you please make me a separate issue for that, lest I forget?

[gracjan]

Thinking about this one a bit more I reckon that I have Directory Local Variables in my xxxx.cabal file (instead of emacs specific things) and my File Local Variables in the form of {-# ... #-} (instead of emacs specific). It is a shame to treat them in a different way than those in emacs specific files.

[swsnr]

@gracjan I'm sorry, but I can't follow you on your last comment…

[gracjan]

Might be language issue, but by 'follow' do you mean that you do not understand or do you mean that you disagree?

[swsnr]

The former.

[gracjan]

In equations:
my-project.cabal === .dir-locals.el
{-# OPTIONS_GHC .... #-} === -- mode: haskell --

Just like settings from .dir-locals.el overwrite previously set variables so should settings from my-project.cabal overwrite (NOT append to) settings set previously.

[swsnr]

@gracjan I'm still not getting what you are trying to tell me.