bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41250: 28.0.50; Dired displays unconditionally ls-switches on modeli


From: Arthur Miller
Subject: bug#41250: 28.0.50; Dired displays unconditionally ls-switches on modeline
Date: Sun, 17 May 2020 18:34:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: drew.adams@oracle.com,  41250@debbugs.gnu.org,  juri@linkov.net
>> Date: Sun, 17 May 2020 05:01:53 +0200
>> 
>> I have introduced dired-mode-line-hook, which is a usual thing in Emacs,
>> which is ment as a list of hooks that user can set. Each hook should
>> return a string that will be concatenated to the lighter. So users can
>> print whatever they want to that string (number of files, dirs etc).
>> 
>> I have introduced also another function that will just iterate through
>> hooks concat stuff and update the modeline and refactored some code to
>> call this function instead of old dired-sort-set-modeline. Also
>> dired-sort-set-modeline is changed to work as a mentioned hook and is
>> used as default value for dired-mode-line-hook.
>> 
>> If user does not prefer to see any aditional info on modeline then it is
>> just to set dired-mode-line-hook to nil. Obs, that can probably be coded
>> more elegantly, me & elisp are maybe not best friends (yet :-)). I have
>> built and tested emacs with the patch, but I might have missed
>> something.
>
> Once again, I think users should have simple means to request simple
> variations in behavior.  A hook is not a simple means, it requires
> non-trivial knowledge of Lisp.  So it should not be the only or main
> solution to such problems.
I agree with what you say about elisping requiring more knowledge on
users end, of course.

Allowing for hooks is quite standard and usual in Emacs, so in that
regard, it fits into the "emacs way", if I can call it so (and also a
cheap way to get away with this :-)), but yes I agree it is not a newbie
friendly. Really newbie friendly would involve adding more regexps, say
for type and size and maybe some other "important" criteria, and also
adding means of controlling display of those on modeline, either via
customize (bunch of variables) or by some kind of gui I guess.

Another considerations is that this really is a minor change, since this
behaviour of Dired has existed for so long and nobody but me seems to
complain about it. I guess, not many people are using dired in way I do,
and/or are bothered by ls switches pushing stuff away on modeline. While
I was looking to see if there was a solution before I coded mine, I
couldn't find anyone asking on forums or SX about this, so I guess it
was more of "advanced" usage anyway?

In conclusion, it might be a lot of work for quite little regard in
terms of how much people would use it. A hook is not that as nice
as a gui of course, but it is still better then nothing. I don't know,
what do you guys think, is it worth? Is there a need for that, I mean,
more than "it would be nice to have"?

Another suggestion:

Instead of displaying ls-switches per se, dired could display just "by
custom". It is consistent with "by name" and "by date" as of currently.
Then when user hoovers over that part "by ..." the tooltip showing
actuall regexp could be shown.

I have a technical question regarding this: is it possilbe to detect in
elisp when pointer howers over part of a string, i.e. part of mode-name
on a lighter, since a lighter is a button. Would this be quite involved
or it can be implemented easily?

>> While I was looking through the code to set myself into dired, I have
>> also noticed lots of '^L' chars, I took the freedom to clean it up where
>> I saw them, there are probably more.
>
> You shouldn't remove them, they divide large files into sections, and
> make it easy to move by "pages".
Aha, that is why all those were there; I didn't know. Sorry, I'll never
ever touch them again :-). Thanks for the explanation.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]