punassuming / ranger.el

Bringing the goodness of ranger to dired!
700 stars 52 forks source link

hl-line-mode left enabled after disabling ranger-mode #13

Closed vifon closed 9 years ago

vifon commented 9 years ago

ranger-mode enables the hl-line-mode but does not restore its state after being disabled. Would it be possible to restore its state?

punassuming commented 9 years ago

Yes, thanks for the catch. Looks like I will have to save the state. The problem is that we dont always disable ranger when we move to a new file. When is this normally happening for you: when entering a file from ranger, when moving to a file using an external function, or just everywhere?

vifon commented 9 years ago

I'm not sure if I understand the question. Still, let me elaborate on the issue. hl-line-mode seems to be enabled in the dired buffers used by the ranger-mode's columns on the left (the parent directories). If I enter a directory with ranger-mode, hl-line-mode is not enabled. If I then enter its subdirectory and go back, hl-line-mode is enabled now and it will be enabled until I disable it manually (disabling ranger-mode does not disable it).

There is a similar issue with the header-line-format variable still containing the ranger-mode's information in some buffers. I didn't check exactly but it seems to be properly disabled in the buffers visible when the ranger-mode is being disabled but it lingers in the other dired buffers previously visited using ranger-mode.

punassuming commented 9 years ago

@Vifon, I played with saving hl-line-mode on entrance and restoring on exit. Let me know if this helps. 439bba60e1c64b5c87f2dcb31cb7100b0ad429b5. Try the current master and let me know if you still have issues.

vifon commented 9 years ago

hl-line-mode still behaves just like before. Apart from that, M-x ranger doesn't work. When I tried to enable ranger-mode manually, I got this: progn: Symbol's value as variable is void: hl-line-mode. I then enabled and disabled hl-line-mode to load it (I suppose it wasn't loaded at that point). Then ranger-mode worked but behaves mostly just as before.

punassuming commented 9 years ago

I made some changes last night that changed reverting buffers, so hopefully it reverts properly now, but I will look into whether I must call to require hl-line-mode in the first place.

punassuming commented 9 years ago

@vifon, you mind if I call my new minimal mode (called by ranger-same-window) deer-mode?

vifon commented 9 years ago

No problem, go for it. :)

punassuming commented 9 years ago

@Vifon, I fixed a couple issues where packages I used (like hl-line), were not required explictely. This should fix the one issue you had.

vifon commented 9 years ago

I confirm the issues with loading hl-line-mode. The original issue still exists: When I exit ranger-mode, I am shown the file in which I've originally ran it. If I open a dired buffer with its directory, the ranger-mode's header-line-format and hl-line-mode state is still active.

punassuming commented 9 years ago

@Vifon, I am reverting the appearance of the previous ranger buffer on exit now, so it should resolve the issue you were seeing. At least it has with me. hl-line and the header is reverted if I exit by q and go back into directory (with dired-jump).

vifon commented 9 years ago

Still happens in some cases. My scenario in which it always works (i.e. the appearance is not reverted):

  1. Open ranger.el and call eval-buffer there. It is located in ~/src/ranger.el/ranger.el. The nest level may be important, who knows.
  2. M-x ranger.
  3. Go one directory up (i.e. press h).
  4. Press q to exit the ranger-mode.
  5. M-x dired-jump

Personally, I would ditch the visual modifications of the dired buffers, but I understand if you need/want/use them. I would be pretty happy with just the keymap and the Miller columns. Though reverting the visuals and disabling the keymap seem to be one and the same problem, so it might not be of much help.

punassuming commented 9 years ago

@vifon, this is getting frustrating, as every time I send a response, I think I have it fixed and then I find another issue. :) I started with emacs -Q, and I was not able to reproduce that issue directly, but did see an issue with the way I loaded dired-x. I fixed that and can go through your exact scenario and get the buffer reverted properly. This is both in vanilla emacs and spacemacs as well Are you producing this with no other packages, or do you have packages already installed?

In terms of simplified usage, I will modify the way I have headers set so that we can customize and disable visual modifications.

vifon commented 9 years ago

this is getting frustrating, as every time I send a response, I think I have it fixed and then I find another issue

Yeah, sorry about that. Every time I report it's still there I feel like a bad guy.

I've just checked with emacs -Q just in case (commit 6f8d919). Still reproduces.

punassuming commented 9 years ago

Don't feel like the bad guy, I like doing the troubleshooting. So now we go to versioning. What version of Emacs do you use? What system are you running?

vifon commented 9 years ago

GNU Emacs 25.0.50.2, built from the commit 5dc72bc4 on Ubuntu Server 15.04.

punassuming commented 9 years ago

One last thing, is this from terminal or desktop? I will make a virtual machine to test out this week.

vifon commented 9 years ago

The GUI Emacs ("desktop", I suppose) but it shouldn't matter. Good idea. I'll try to prepare a Docker image reproducing it, just in case. Probably on weekend.

vifon commented 9 years ago

Ok, so here's a Dockerfile that reproduces one of the ways this bug manifests.

FROM base/arch

RUN pacman -Sy --noconfirm emacs-nox gnutls git

RUN useradd -m developer
USER developer

ENV HOME /home/developer

RUN mkdir $HOME/src && \
    git clone https://github.com/ralesi/ranger $HOME/src/ranger.el

ENTRYPOINT emacs --eval '(let ((ranger "~/src/ranger.el/ranger.el")) (load-file ranger) (find-file ranger) (ranger) (ranger-disable) (dired "."))'

Use it with docker build -t some-name . and docker run -it --rm some-name. Analyze the last line of the Dockerfile to see what exactly I do to reproduce the issue.

punassuming commented 9 years ago

Thanks for the info. Recent commits have completely wiped the buffer from existence. I now kill all accessed buffers from ranger. I did find a few issues with reverting dired-hide-details back to default, which I also addressed. I was able to see hl-line-mode enabled on revert after traversal up a directory, but now that the dired buffer is killed on exit, it should definitely be reverted on load again. Setting ranger-cleanup-on-disable to nil should keep the buffers around, and in that case, it looks like with the changes, dired is reverted back properly.

vifon commented 9 years ago

Seems to be working fine. Thanks!