GNU bug report logs -
#41250
28.0.50; Dired displays unconditionally ls-switches on modeline
Previous Next
Reported by: Arthur Miller <arthur.miller <at> live.com>
Date: Thu, 14 May 2020 01:43:01 UTC
Severity: minor
Tags: fixed
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41250 in the body.
You can then email your comments to 41250 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 14 May 2020 01:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Arthur Miller <arthur.miller <at> live.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 14 May 2020 01:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
There is no way to turn off displaying of ls-switches on modeline when
in dired-mode.
By default in certain configuration, dired display ls-switches on
modeline. In case those switches are a long list, for example:
"-lA --si --time-style long-iso --group-directories-first"
then everything else on modeline gets pushed far to the right which is
not very usable. In general I don't have much use of seing ls-switches
on modeline and would like to be able to turn them off. As of current it
does not seem possible since it is hard-coded in function
`dired-sort-set-mode-line' in dired.el.
I suggest, as small improvement, to introduce a user option to turn off
or on displaying of ls-switches on modeline. As a suggestion I have
attached small hack to dired.el as tested on my copy of Emacs, but you
might wish to rewrite it. Drew had some other suggestions.
[dired.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 14 May 2020 22:43:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> There is no way to turn off displaying of ls-switches on modeline when
> in dired-mode.
>
> By default in certain configuration, dired display ls-switches on
> modeline. In case those switches are a long list, for example:
>
> "-lA --si --time-style long-iso --group-directories-first"
>
> then everything else on modeline gets pushed far to the right which is
> not very usable. In general I don't have much use of seing ls-switches
> on modeline and would like to be able to turn them off. As of current it
> does not seem possible since it is hard-coded in function
> `dired-sort-set-mode-line' in dired.el.
>
> I suggest, as small improvement, to introduce a user option to turn off
> or on displaying of ls-switches on modeline. As a suggestion I have
> attached small hack to dired.el as tested on my copy of Emacs, but you
> might wish to rewrite it. Drew had some other suggestions.
Maybe instead of boolean better to use a number for the allowed limit
that should not grow more than this number that means the length of
switches string that the user can tolerate on the modeline.
Then modeline will display abbreviation truncated to the specified
number of characters, with an ellipses, on the assumption that
the most important switches are at the beginning of the string.
Customizing it to 0 effectively disables the display of switches.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 14 May 2020 23:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> Maybe instead of boolean better to use a number for the allowed limit
> that should not grow more than this number that means the length of
> switches string that the user can tolerate on the modeline.
>
> Then modeline will display abbreviation truncated to the specified
> number of characters, with an ellipses, on the assumption that
> the most important switches are at the beginning of the string.
> Customizing it to 0 effectively disables the display of switches.
I suggested a choice, one possibility being a format string.
A format string also lets you truncate. But sure, another
choice offered could be what you suggest (a simpler way to
specify just truncation).
I made the suggestion in an emacs-devel thread, which hasn't
been referenced so far in this bug thread:
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01851.html
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01964.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 06:45:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Fri, 15 May 2020 01:33:51 +0300
> Cc: 41250 <at> debbugs.gnu.org
>
> > I suggest, as small improvement, to introduce a user option to turn off
> > or on displaying of ls-switches on modeline. As a suggestion I have
> > attached small hack to dired.el as tested on my copy of Emacs, but you
> > might wish to rewrite it. Drew had some other suggestions.
>
> Maybe instead of boolean better to use a number for the allowed limit
> that should not grow more than this number that means the length of
> switches string that the user can tolerate on the modeline.
>
> Then modeline will display abbreviation truncated to the specified
> number of characters, with an ellipses, on the assumption that
> the most important switches are at the beginning of the string.
That sounds better. Bonus points for arranging a tooltip that would
show the full string when the mouse is over that part of the mode
line.
> Customizing it to 0 effectively disables the display of switches.
Why not simply use nil? We could use zero, but that is a bit
"tricky", and doesn't seem to me justified in this case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 08:41:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Date: Fri, 15 May 2020 01:33:51 +0300
>> Cc: 41250 <at> debbugs.gnu.org
>>
>> > I suggest, as small improvement, to introduce a user option to turn off
>> > or on displaying of ls-switches on modeline. As a suggestion I have
>> > attached small hack to dired.el as tested on my copy of Emacs, but you
>> > might wish to rewrite it. Drew had some other suggestions.
>>
>> Maybe instead of boolean better to use a number for the allowed limit
>> that should not grow more than this number that means the length of
>> switches string that the user can tolerate on the modeline.
>>
>> Then modeline will display abbreviation truncated to the specified
>> number of characters, with an ellipses, on the assumption that
>> the most important switches are at the beginning of the string.
>
> That sounds better. Bonus points for arranging a tooltip that would
> show the full string when the mouse is over that part of the mode
> line.
Currently, if I disable ls-switches, it displays just "(Dired)" on
modeline, as I coded in my patch. When mouse is over it displays
help-tooltip, ("Major mode", "Mouse1 - ..." etc). Is it maybe better to
put ls-switches as a submenu to pop-up menu that appears when one click
with mouse button1? Or how do you imagine the tooltip - to replace one
with help or soemthing else?
I don't know how to add a submenu to that pop-up or a tooltip, but I can
look it up.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 08:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> Maybe instead of boolean better to use a number for the allowed limit
>> that should not grow more than this number that means the length of
>> switches string that the user can tolerate on the modeline.
>>
>> Then modeline will display abbreviation truncated to the specified
>> number of characters, with an ellipses, on the assumption that
>> the most important switches are at the beginning of the string.
>> Customizing it to 0 effectively disables the display of switches.
>
> I suggested a choice, one possibility being a format string.
> A format string also lets you truncate. But sure, another
> choice offered could be what you suggest (a simpler way to
> specify just truncation).
>
> I made the suggestion in an emacs-devel thread, which hasn't
> been referenced so far in this bug thread:
>
> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01851.html
>
> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01964.html
I answered you on that mail, but I just mentioned that you had other
suggestion on bug repport just for the simplicity. I think format string
asks for more documentation and more cognitive effort on part of user
:-) and as such maybe it is better to have it as part of Dired+.
Kind-of more for hard-core users who prefer much deeper level of
customization?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 10:17:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: Juri Linkov <juri <at> linkov.net>, 41250 <at> debbugs.gnu.org
> Date: Fri, 15 May 2020 10:40:34 +0200
>
> > That sounds better. Bonus points for arranging a tooltip that would
> > show the full string when the mouse is over that part of the mode
> > line.
>
> Currently, if I disable ls-switches, it displays just "(Dired)" on
> modeline, as I coded in my patch. When mouse is over it displays
> help-tooltip, ("Major mode", "Mouse1 - ..." etc). Is it maybe better to
> put ls-switches as a submenu to pop-up menu that appears when one click
> with mouse button1? Or how do you imagine the tooltip - to replace one
> with help or soemthing else?
Figuring this out is part of the job, I guess. One possibility would
be to show the tooltip only when the imaginary defcustom is non-nil,
i.e. when the user expressed his/her desire to see the switches, but
there's no space to show them in their entirety. Maybe there are
other possibilities, I didn't think long enough about this to tell.
As for the mode tooltip, I think you could work around the problem by
making the switches tooltip pop up only on the partial text of the
switches, not on the mode string itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 10:52:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: Juri Linkov <juri <at> linkov.net>, 41250 <at> debbugs.gnu.org
>> Date: Fri, 15 May 2020 10:40:34 +0200
>>
>> > That sounds better. Bonus points for arranging a tooltip that would
>> > show the full string when the mouse is over that part of the mode
>> > line.
>>
>> Currently, if I disable ls-switches, it displays just "(Dired)" on
>> modeline, as I coded in my patch. When mouse is over it displays
>> help-tooltip, ("Major mode", "Mouse1 - ..." etc). Is it maybe better to
>> put ls-switches as a submenu to pop-up menu that appears when one click
>> with mouse button1? Or how do you imagine the tooltip - to replace one
>> with help or soemthing else?
>
> Figuring this out is part of the job, I guess. One possibility would
> be to show the tooltip only when the imaginary defcustom is non-nil,
> i.e. when the user expressed his/her desire to see the switches, but
> there's no space to show them in their entirety. Maybe there are
> other possibilities, I didn't think long enough about this to tell.
>
> As for the mode tooltip, I think you could work around the problem by
> making the switches tooltip pop up only on the partial text of the
> switches, not on the mode string itself.
Ok. I'll think about it more and see what I can come up with.
An impuls idea is to have the variable as a stae: nil, short, long, where nil
will hide ls-switches completely, short will show them shortened and
long will display ls-switches entirely, and tooltip could then be shown
when mouse is over the short version.
I will have to look up how to code this with tooltip, but I'll try to
code it :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 18:59:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I think format string asks for more documentation and
> more cognitive effort on part of user :-) and as such
> maybe it is better to have it as part of Dired+.
>
> Kind-of more for hard-core users who prefer much
> deeper level of customization?
Emacs users are of all kinds. No user who
doesn't understand `format' would need to
make that particular option-value choice.
This is no different from options we have
that have a catch-all choice of a function,
which they can use to get pretty much any
behavior.
And that's another reasonable alternative
here to a choice of a format string: a
function that accepts the current switches
as its (first) argument.
That's even more general, and it wouldn't
freak out a user unfamiliar with format
strings. ;-)
And that also covers truncating, trivially.
There's nothing special about truncating.
It just happens to correspond directly to
your immediate problem: a long list of
switches.
Attached is a patch that does what I think
should be done. The option value can be:
nil - to get the current behavior
`as-is' - show the full switches
an integer - show first N chars of switches
a function - show whatever it returns, when
passed `dired-actual-switches'
If Emacs doesn't want to go this route then
I guess I'll just use it for Dired+.
___
I do think your suggestion of mouseover
the mode-line indication showing the full
switches is a good one.
I've added command `diredp-change-ls-switches'
to Dired+, and added it to menu-bar menu `Dir'
(aka `Subdir'). It shows the current switches
in the prompt, so you can just hit `C-g' if all
you want is see what the current switches are.
And because it's in the menu, you can get to
it by clicking the lighter in the mode-line.
(Menu `Dir' is the first menu listed when you
click.)
[dired-2020-05-15a.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 19:10:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 15 May 2020 11:55:46 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 41250 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>
> an integer - show first N chars of switches
I don't think this is a useful value: the user will rarely know how
much space is available on the mode line. Also, truncating without
showing ellipsis or some other sign of truncation is IMO a sub-optimal
UI.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 19:55:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> Attached is a patch that does what I think
> should be done. The option value can be:
>
> nil - to get the current behavior
> `as-is' - show the full switches
> an integer - show first N chars of switches
> a function - show whatever it returns, when
> passed `dired-actual-switches'
Cool. I was actually sitting and coding but you have already done it,
nice.
I have just one question/suggestion:
You first choice: indicate by name or date, else full. Does it really
need to be there? ls-switches are displayed only when dired is not
sorted by name or date, i.e. custom hence displaying ls switches as part
of mode name. Thus this customization only touches displaying of
switches when they are displayd. I.e. it should be about "how", not "when".
To explain my thought: that is a hard-coded behaviour which user can't
customize anway. By looking at your code, that bevahviour indeed
persists. 2nd choice is the one that actually consider how switches will
be displayed.
I have same consideration about 3rd choice too. Function choice gives
option to run custom hook as format. I think it is cool to have custom
format function to display when in dired mode, so I like it, but it is a
bit different purpose then regulating display of switches. As I perceive it.
Maybe it should get it's own custom variable instead? Like
dired-mode-line-display-hook or something similar?
2nd option, one with number does what the proposed variable name
suggests. Personally I ment to code just short (first switch) and long
(all switches), since probably the first one is the most important one.
I would also prefer nil to mean don't show switches at all, but it works
with N chars set to 0 as well I guess.
Observe also that if I turn off display by using 0 chars as suggested
there will be a small gap between word "Dired" and closing parenthesis.
It will look like: (Dired ) on modeline. Not a deal breaker, but kind of
small artefact. Easily fixed though. I can rework it if you wish, but
since it is yours, you might prefer to do it yourself.
That is just my opinion, in general I think it does the jobb anyway, so
if you guys are happy, I am happy. As long as it is possible to get rid
of switches on modeline in some way, it is an improvement.
> diff -u dired.el dired-2020-05-15a-PATCHED.el
> --- dired.el 2020-05-15 11:23:32.804823800 -0700
> +++ dired-2020-05-15a-PATCHED.el 2020-05-15 11:26:20.702051000 -0700
> @@ -4114,22 +4114,40 @@
> "Non-nil means the Dired sort command is disabled.
> The idea is to set this buffer-locally in special Dired buffers.")
>
> +(defcustom dired-switches-in-mode-line nil
> + "How to indicate `dired-actual-switches' in mode-line.
> +Possible values:
> + * `nil': Indicate name-or-date sort order, if possible.
> + Else show full switches.
> + * `as-is': Show full switches.
> + * Integer: Show only the first N chars of full switches.
> + * Function: Pass `dired-actual-switches' as arg and show result."
> + :group 'Dired-Plus
> + :type '(choice
> + (const :tag "Indicate by name or date, else full" nil)
> + (const :tag "Show full switches" as-is)
> + (integer :tag "Show first N chars of switches" :value 10)
> + (function :tag "Format with function" :value identity)))
> +
> (defun dired-sort-set-mode-line ()
> - ;; Set mode line display according to dired-actual-switches.
> - ;; Mode line display of "by name" or "by date" guarantees the user a
> - ;; match with the corresponding regexps. Non-matching switches are
> - ;; shown literally.
> + "Set mode-line according to option `dired-switches-in-mode-line'."
> (when (eq major-mode 'dired-mode)
> (setq mode-name
> - (let (case-fold-search)
> - (cond ((string-match-p
> - dired-sort-by-name-regexp dired-actual-switches)
> - "Dired by name")
> - ((string-match-p
> - dired-sort-by-date-regexp dired-actual-switches)
> - "Dired by date")
> - (t
> - (concat "Dired " dired-actual-switches)))))
> + (let ((case-fold-search nil))
> + (if dired-switches-in-mode-line
> + (concat "Dired "
> + (cond ((integerp dired-switches-in-mode-line)
> + (substring dired-actual-switches
> + 0 dired-switches-in-mode-line))
> + ((functionp dired-switches-in-mode-line)
> + (format "%s" (funcall dired-switches-in-mode-line
> + dired-actual-switches)))
> + (t dired-actual-switches)))
> + (cond ((string-match-p dired-sort-by-name-regexp dired-actual-switches)
> + "Dired by name")
> + ((string-match-p dired-sort-by-date-regexp dired-actual-switches)
> + "Dired by date")
> + (t (concat "Dired " dired-actual-switches))))))
> (force-mode-line-update)))
>
> (define-obsolete-function-alias 'dired-sort-set-modeline
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 21:01:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > an integer - show first N chars of switches
>
> I don't think this is a useful value: the user will rarely know how
> much space is available on the mode line.
A user may know how much space they're willing
to give to this, as a general preference/rule.
Mode-line data can vary considerably, depending
on one's setup, the buffer's mode, and other
things. And the effective available space
depends on window width.
So of course no particular truncation constant
length will fit all contexts. Such truncation
is of limited utility, IMO, but I thought that's
what was requested.
Sure, truncation could instead be relative (%).
In that case what it's relative to needs to be
considered.
This is why, in the general case, a function
value is there. You'll recall that in an earlier
mail I said that truncation can just be done by
such a function. (Well, at that point I said a
`format' string - that too can truncate.)
What I wrote up is just a simple truncation. If
you have a better one you want to suggest, fine.
> Also, truncating without showing ellipsis or some
> other sign of truncation is IMO a sub-optimal UI.
Arguable - mode-line space is limited. But maybe.
I imagine you're suggesting appending a char such
as `.' to whatever truncation is used. That's
fine by me (though I'm not crazy about that char,
which I find generally illegible). An alternative
(more readable, but wastes 2 more chars, is `...'.
Another alternative is to surround the set of
switches with delimiters, e.g. "" or '' or [] ...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 21:09:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 15 May 2020 11:55:46 -0700 (PDT)
>> From: Drew Adams <drew.adams <at> oracle.com>
>> Cc: 41250 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>>
>> an integer - show first N chars of switches
>
> I don't think this is a useful value: the user will rarely know how
> much space is available on the mode line. Also, truncating without
> showing ellipsis or some other sign of truncation is IMO a sub-optimal
> UI.
>
> Thanks.
After I saw Drews mail and patch, and answered, I was thinking
additionally, and I am actually now wondering, why is it assumed that
Dired will show sorting order on modeline by default? I mean other modes
does not do similar. Say, cc-mode does not show which current identation
scheme I use, or something similar. Why is it assumed for Dired? I don't
have historical insight so I don't know why original author(s) decided
to make it so?
If Dired show just, word "Dired" as it's lighter only, as other modes do,
then maybe Drews idea to have a format string is maybe the most flexible
one? For example we could have a format string, by default nil or just
"", which user could set to whatever. Or there could be a hook, say
(defun dired-display-mode-line-info (info-message)
(setq mode-name (concat mode-name " " info-message)
(force-mode-line-update)))
with some checks for empty stirng and so on. I ment just as a quick
illustration.
Then users could put for themselves the info they wishes to be
displayed on modeline: sorting order, or number of fles, or current moon
phase? Or they will be like and would prefer to show nothing.
Maybe you have already discussed this when dired was written? In that
case I am just curious why it was decided that Dired should show extra
info on modeline? If anybody remembers, or even know, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 21:16:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> > an integer - show first N chars of switches
>>
>> I don't think this is a useful value: the user will rarely know how
>> much space is available on the mode line.
>
> A user may know how much space they're willing
> to give to this, as a general preference/rule.
>
> Mode-line data can vary considerably, depending
> on one's setup, the buffer's mode, and other
> things. And the effective available space
> depends on window width.
>
> So of course no particular truncation constant
> length will fit all contexts. Such truncation
> is of limited utility, IMO, but I thought that's
> what was requested.
>
> Sure, truncation could instead be relative (%).
> In that case what it's relative to needs to be
> considered.
>
> This is why, in the general case, a function
> value is there. You'll recall that in an earlier
> mail I said that truncation can just be done by
> such a function. (Well, at that point I said a
> `format' string - that too can truncate.)
>
> What I wrote up is just a simple truncation. If
> you have a better one you want to suggest, fine.
>
>> Also, truncating without showing ellipsis or some
>> other sign of truncation is IMO a sub-optimal UI.
>
> Arguable - mode-line space is limited. But maybe.
>
> I imagine you're suggesting appending a char such
> as `.' to whatever truncation is used. That's
> fine by me (though I'm not crazy about that char,
> which I find generally illegible). An alternative
> (more readable, but wastes 2 more chars, is `...'.
> Another alternative is to surround the set of
> switches with delimiters, e.g. "" or '' or [] ...
As I understand Eli, he means, if switches are displayed only partially
on modeline, then after the switch chars there would be an elipsis,
which I understand means "...". I think it is OK since it indicates
that there is more to it which indeed is quite common, but yes it does
take more space on modeline.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 22:05:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> I imagine you're suggesting appending a char such
> as `.' to whatever truncation is used.
^
That was supposed to be a horizontal ellipsis char.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 22:20:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> I am actually now wondering, why is it assumed that
> Dired will show sorting order on modeline by default?
Because it's useful. And it is very common to use
`s', to toggle between name and date sorting. Those
are the common sorts, and switches that match their
regexps are the most common.
Those predefined regexps could presumably be tweaked
to accommodate more patterns that have time in them,
but IMHO it's not worth it.
This mode-line indication is not, primarily, about
showing you the current `ls' switches. It's about
telling you whether files are sorted by name or time.
The relevant function is called `dired-sort-set-mode-line'.
^^^^
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 22:20:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I have just one question/suggestion:
(Actually, it seems like several. ;-)
> You first choice: indicate by name or date, else full. Does it really
> need to be there?
Not sure I understand. Define "need".
I kept the longstanding behavior, by default (option
value nil). If you customize then you override that
default behavior. If you don't customize then nothing
changes for you (good).
> ls-switches are displayed only when dired is not
> sorted by name or date, i.e. custom
My intention is to let a user impose showing switches
even in the case where name or date regexp matches.
And to let a user instead prefer "by name" and "by
date" when they match, but default to showing all
(as now).
> Thus this customization only touches displaying of
> switches when they are displayd. I.e. it should be
> about "how", not "when".
Sorry, I don't follow. Please say what behavior
you want to be able to specify that the proposed
code doesn't provide for.
> To explain my thought: that is a hard-coded behaviour which user can't
> customize anway.
What is "this"? Please give an example of the
behavior you'd like that you don't think you
can get, or that you think is too difficult to
get.
> By looking at your code, that bevahviour indeed
> persists.
If you mean that the longstanding behavior is
still possible, and is even the default, yes.
If you mean something else, please rephrase.
> 2nd choice is the one that actually
> consider how switches will be displayed.
By "2nd choice" I guess you mean showing the
full switches? Or do you mean truncating that?
> I have same consideration about 3rd choice too.
> Function choice
(That's the 4th choice.)
> gives option to run custom hook as format. I think it is cool to have custom
> format function to display when in dired mode, so I like it, but it is
> a bit different purpose then regulating display of switches.
What do you mean? The switches string is passed
as an arg to the function, which can return
anything. It can format and return any part of
that string, or transform it in any way, or
return something descriptive (a la "by name"),
or return something completely unrelated (your
birthday, "Hello world!").
> Maybe it should get it's own custom variable instead? Like
> dired-mode-line-display-hook or something similar?
Why? Then you're essentially back to the idea
of having _only_ a function.
> 2nd option, one with number
(That's the 3rd choice.)
> does what the proposed variable name suggests.
The name just suggests something in the mode-line
that's based on switches.
> Personally I ment to code just short (first switch)
(That's name/date.)
> and long (all switches), since probably the first
> one is the most important one.
Sorry, but I'm lost in your reference to first,
second, etc.
It sounds now like you're not interested in a
truncation choice (?). I thought it was you who
requested that.
> I would also prefer nil to mean don't show switches at all, but it
> works with N chars set to 0 as well I guess.
A value of 0 shows nothing. And so does a value
of (lambda (x) "").
> Observe also that if I turn off display by using 0 chars as suggested
> there will be a small gap between word "Dired" and closing parenthesis.
> It will look like: (Dired ) on modeline. Not a deal breaker, but kind
> of small artefact. Easily fixed though. I can rework it if you wish,
> but since it is yours, you might prefer to do it yourself.
Attached patch takes care of that, and adds ellipsis.
[dired-2020-05-15b.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 15 May 2020 22:25:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry. `diredp' should be `dired' everywhere.
This patch takes care of that typo.
[dired-2020-05-15c.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 16 May 2020 06:35:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 41250 <at> debbugs.gnu.org,
> juri <at> linkov.net
> Date: Fri, 15 May 2020 23:08:46 +0200
>
> After I saw Drews mail and patch, and answered, I was thinking
> additionally, and I am actually now wondering, why is it assumed that
> Dired will show sorting order on modeline by default? I mean other modes
> does not do similar. Say, cc-mode does not show which current identation
> scheme I use, or something similar.
Yes, it does: the CC Mode shows the comment style in use and the minor
mode.
> Why is it assumed for Dired? I don't have historical insight so I
> don't know why original author(s) decided to make it so?
The sorting order was just one letter originally, so it sounds like a
good idea to have an indication of why the order is this and not
another.
> If Dired show just, word "Dired" as it's lighter only, as other modes do,
> then maybe Drews idea to have a format string is maybe the most flexible
> one?
Not IMO. Using format strings and functions is "advanced usage",
which is normally barred for newbies and relatively inexperienced
Emacs users. Popular options should IMO be exposed though easier
customization values.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 16 May 2020 12:19:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: Drew Adams <drew.adams <at> oracle.com>, 41250 <at> debbugs.gnu.org,
>> juri <at> linkov.net
>> Date: Fri, 15 May 2020 23:08:46 +0200
>>
>> After I saw Drews mail and patch, and answered, I was thinking
>> additionally, and I am actually now wondering, why is it assumed that
>> Dired will show sorting order on modeline by default? I mean other modes
>> does not do similar. Say, cc-mode does not show which current identation
>> scheme I use, or something similar.
>
> Yes, it does: the CC Mode shows the comment style in use and the minor
> mode.
>
>> Why is it assumed for Dired? I don't have historical insight so I
>> don't know why original author(s) decided to make it so?
>
> The sorting order was just one letter originally, so it sounds like a
> good idea to have an indication of why the order is this and not
> another.
>
>> If Dired show just, word "Dired" as it's lighter only, as other modes do,
>> then maybe Drews idea to have a format string is maybe the most flexible
>> one?
>
> Not IMO. Using format strings and functions is "advanced usage",
> which is normally barred for newbies and relatively inexperienced
> Emacs users. Popular options should IMO be exposed though easier
> customization values.
Oki, I understand. To me, this info on modeline is superflous. When I am
in dired buffer, I have immidiate visual feedback by just lookig at the
content. I see if the content is sorted alhabetically or by some other
means, for example size (which is not reflected at all on modeline.)
Also I like the possibility of user having option to customize
this like everything else in Emacs. I will try to code another idea
later in the evening as another suggestion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 16 May 2020 14:43:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > maybe Drews idea to have a format string is
> > maybe the most flexible one?
A function, rather than just a format string, is
clearly the most flexible one, of the ones I made
available as choices for the option value.
And many more users will know how to define a
simple function that returns something than will
necessarily know about `format' etc.
> Not IMO. Using format strings and functions is
> "advanced usage", which is normally barred for
> newbies and relatively inexperienced Emacs users.
> Popular options should IMO be exposed though
> easier customization values.
Where is it barred to have an option `choice'
that allows for a function value?
If that were the case then we would presumably
not even have `function' as a `defcustom' type.
Likewise other types, such as `regexp' and `alist'.
The Customize UI is, after all, for newbies too.
Some (not I) think it is primarily or _only_ for
newbies.
But more importantly, there are also very simple
choices defined for this option (and `function'
is the last in `Value Menu'). And the default
behavior is nil - which keeps the longstanding
behavior.
Nothing obliges a newbie to customize the option
to a function value. Barring the use of options
that have a function - or a regexp, for that
matter - as one of a set of `choice's would be
very wrong, IMHO. And I don't see such a barring
or convention anywhere in the doc.
Anyway, do what you want. If this isn't taken
up by vanilla Emacs I'll use it in Dired+. My
preference is for vanilla Emacs to do it, to
lessen my own maintenance burden, but it's not
a big deal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 16 May 2020 23:25:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> nil - to get the current behavior
> `as-is' - show the full switches
> an integer - show first N chars of switches
> a function - show whatever it returns, when
> passed `dired-actual-switches'
Instead of `as-is' a simpler value could be just `t'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 01:17:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > nil - to get the current behavior
> > `as-is' - show the full switches
> > an integer - show first N chars of switches
> > a function - show whatever it returns, when
> > passed `dired-actual-switches'
>
> Instead of `as-is' a simpler value could be just `t'.
Simpler how? Because it's self-evaluating? :as-is
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 03:03:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: Drew Adams <drew.adams <at> oracle.com>, 41250 <at> debbugs.gnu.org,
>> juri <at> linkov.net
>> Date: Fri, 15 May 2020 23:08:46 +0200
>>
>> After I saw Drews mail and patch, and answered, I was thinking
>> additionally, and I am actually now wondering, why is it assumed that
>> Dired will show sorting order on modeline by default? I mean other modes
>> does not do similar. Say, cc-mode does not show which current identation
>> scheme I use, or something similar.
>
> Yes, it does: the CC Mode shows the comment style in use and the minor
> mode.
>
>> Why is it assumed for Dired? I don't have historical insight so I
>> don't know why original author(s) decided to make it so?
>
> The sorting order was just one letter originally, so it sounds like a
> good idea to have an indication of why the order is this and not
> another.
>
>> If Dired show just, word "Dired" as it's lighter only, as other modes do,
>> then maybe Drews idea to have a format string is maybe the most flexible
>> one?
>
> Not IMO. Using format strings and functions is "advanced usage",
> which is normally barred for newbies and relatively inexperienced
> Emacs users. Popular options should IMO be exposed though easier
> customization values.
Ok, what about this strategy:
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.
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.
[dired.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 03:11:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> I am actually now wondering, why is it assumed that
>> Dired will show sorting order on modeline by default?
>
> Because it's useful. And it is very common to use
> `s', to toggle between name and date sorting. Those
> are the common sorts, and switches that match their
> regexps are the most common.
>
> Those predefined regexps could presumably be tweaked
> to accommodate more patterns that have time in them,
> but IMHO it's not worth it.
>
> This mode-line indication is not, primarily, about
> showing you the current `ls' switches. It's about
> telling you whether files are sorted by name or time.
>
> The relevant function is called `dired-sort-set-mode-line'.
> ^^^^
Yeah, I completely understand, but as I wrote to Eli too, to me, dired
buffer itself is an immidate visual feedback. I don't need addtional
information on modeline to tell me if files are sorted alfabetically or
by some other mean. So I prefer to save mode-line space for something
else. It is just my personal preference, I have understanding that other
people might have different taste.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 07:00:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > This mode-line indication is not, primarily, about
> > showing you the current `ls' switches. It's about
> > telling you whether files are sorted by name or time.
>
> Yeah, I completely understand, but as I wrote to Eli too, to me, dired
> buffer itself is an immidate visual feedback. I don't need addtional
> information on modeline to tell me if files are sorted alfabetically or
> by some other mean.
Some of us do need/want that aid. And no,
it's not always obvious what the current order
is.
> So I prefer to save mode-line space for something
> else. It is just my personal preference, I have
> understanding that other people might have different taste.
Indeed; likewise. And I'm in favor of making
it easy for different people to get different
behavior in this regard.
In general, user customization of the mode-line
is not simple. When a mode like Dired can offer
useful info in the mode-line, in a few chars, it
should. And when it can offer users easy ways
to change what's shown there and how, it should.
That doesn't mean that providing a few simple
choices and simple ways to choose will satisfy all
user desires in this department. Fortunately ;-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 11:14:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> That doesn't mean that providing a few simple
> choices and simple ways to choose will satisfy all
> user desires in this department. Fortunately ;-).
Indeed! If one aim to satisfy everybody one ends satisfying nobody
... usually (I talk about software platorms and architecture :-)).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 15:18:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: drew.adams <at> oracle.com, 41250 <at> debbugs.gnu.org, juri <at> 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.
> 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".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 16:36:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: drew.adams <at> oracle.com, 41250 <at> debbugs.gnu.org, juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 16:44:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: drew.adams <at> oracle.com, 41250 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Sun, 17 May 2020 18:34:53 +0200
>
> 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?
You need to define different help-echo strings for different parts of
the string, using text properties. You can see how this is done in
bindings.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 22:58:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: drew.adams <at> oracle.com, 41250 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Sun, 17 May 2020 18:34:53 +0200
>>
>> 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?
>
> You need to define different help-echo strings for different parts of
> the string, using text properties. You can see how this is done in
> bindings.el.
Yes.
Another question: can I assume, at this time of civilisation
development, that everybody has GNU ls, since binutils, or coreutils, or
what is the name, is probably default on most *nix distros, as well as
on msys2 which is needed to build on Windows. No idea how Mac people are
doing in that regard though?
If we can assume that, then I can add sort by extension & size, and
feature to group dirs first and reverse sort.
I can try to detect if gnu ls is present say when dired-mode is
loaded, but that would slow down dired every time we open a directory.
I can also make a customize option for user to enable those regexpes
which requires that user is knowledgable what he/she has on the system,
but maybe it is fairly safe to assume that most people have gnu ls
these days?
:-) Sorry ...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 17 May 2020 23:38:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Arthur Miller <arthur.miller <at> live.com> writes:
> Another question: can I assume, at this time of civilisation
> development, that everybody has GNU ls, since binutils, or coreutils, or
> what is the name, is probably default on most *nix distros, as well as
> on msys2 which is needed to build on Windows. No idea how Mac people are
> doing in that regard though?
MacOS has BSD userland, as does *BSD.
You can install it and use GNU coreutils optionally, but I would expect
only a minority of users to do that.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 18 May 2020 14:27:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: drew.adams <at> oracle.com, 41250 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Mon, 18 May 2020 00:57:42 +0200
>
> Another question: can I assume, at this time of civilisation
> development, that everybody has GNU ls, since binutils, or coreutils, or
> what is the name, is probably default on most *nix distros, as well as
> on msys2 which is needed to build on Windows. No idea how Mac people are
> doing in that regard though?
No, we cannot assume GNU 'ls', since both *BSD Unix systems and macOS
(which is BSD-ish) use non-GNU 'ls'.
> I can try to detect if gnu ls is present say when dired-mode is
> loaded, but that would slow down dired every time we open a directory.
Don't we already detect GNU 'ls' by looking at the //DIRED signature?
Look in files.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 18 May 2020 15:09:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Arthur Miller <arthur.miller <at> live.com> writes:
>
>> Another question: can I assume, at this time of civilisation
>> development, that everybody has GNU ls, since binutils, or coreutils, or
>> what is the name, is probably default on most *nix distros, as well as
>> on msys2 which is needed to build on Windows. No idea how Mac people are
>> doing in that regard though?
>
> MacOS has BSD userland, as does *BSD.
>
> You can install it and use GNU coreutils optionally, but I would expect
> only a minority of users to do that.
>
> Best regards,
> Stefan Kangas
Alright, thanks. I can then either opt for status quo, as it is now
(just date and name) or add extra sort options and bool flag in
defcustom for users to enable if they now they have gnu ls. I could also
add utility funciton to print version of ls in say message buffer.
Anyway I have red the manual about propertize and seen some examples in
code that Eli pointed me to, online aw well, and as I understand this
feature (help-echo) is fairly trivial and easy to use. I like it, it
seems really usefull. However, for some reason modeline ignores my
propertized string :-).
Below is another sketch for this. Instead of displaying actual switches,
I display string "by user". I tested with elipsis at the end, "by
user...", but I don't think it lookes so nice on modeline. The strategy
is to show the tooltip with switches when user hoovers with pointer over
the modeline (I completely missed that feature of Emacs since I use
mouse and modeline so little :-)).
Attached is a patch with this sketch, the only problem seems that I
missundestand something, seems modeline does not display the tooltip.
I am sorry for me being such noob, I will look around more, but if
somebody can point out the misstake it will be helpful.
[dired.patch (text/x-patch, inline)]
--- dired.el 2020-05-14 03:06:34.046112281 +0200
+++ lisp/dired.el 2020-05-18 13:37:21.934674831 +0200
@@ -223,6 +223,14 @@
(define-obsolete-variable-alias 'dired-free-space-args
'directory-free-space-args "27.1")
+(defcustom dired-sort-mode-line-info t
+ "Run when dired is displaying it's info on modeline. Default hook is
+dired-set-sort-mode-line, which displays sorting order used in current
+ dired buffer. Every hook in the list should return a string that
+ will be appended to dired info already shown on modeline."
+ :group 'dired
+ :type 'boolean)
+
;;; Hook variables
(defcustom dired-load-hook nil
@@ -4114,24 +4122,43 @@
"Non-nil means the Dired sort command is disabled.
The idea is to set this buffer-locally in special Dired buffers.")
-(defun dired-sort-set-mode-line ()
- ;; Set mode line display according to dired-actual-switches.
- ;; Mode line display of "by name" or "by date" guarantees the user a
- ;; match with the corresponding regexps. Non-matching switches are
- ;; shown literally.
+(defun dired-set-mode-line ()
+ ;; Flush dired info to mode-line (eval all dired-mode-line-hook)
+ ;; If dired-mode-line-hook is nil, it means user has manually
+ ;; disabled displaying of Dired info on mode-line, so let's respect
+ ;; the user decision.
(when (eq major-mode 'dired-mode)
- (setq mode-name
- (let (case-fold-search)
- (cond ((string-match-p
- dired-sort-by-name-regexp dired-actual-switches)
- "Dired by name")
- ((string-match-p
- dired-sort-by-date-regexp dired-actual-switches)
- "Dired by date")
- (t
- (concat "Dired " dired-actual-switches)))))
+ (if dired-sort-mode-line-info
+ (setq mode-name
+ (concat
+ mode-name
+ (propertize
+ (dired-sort-set-mode-line)
+ 'help-echo dired-actual-switches)))
+ (setq mode-name "Dired")) ;; reset name if dired-mode-line-hook is nil
(force-mode-line-update)))
+(defun dired-sort-set-mode-line ()
+ "Set mode line display according to dired-actual-switches.
+ Mode line display of \"by name\" or \"by date\" guarantees the user a
+ match with the corresponding regexps. Non-matching switches are
+ shown as \"by user\". has not disabled displaying them by
+ customizing dired-display-listing-switches variable."
+ (when (eq major-mode 'dired-mode)
+ (let* ((mode-line-info)
+ (case-fold-search))
+ (cond ((string-match-p
+ dired-sort-by-name-regexp dired-actual-switches)
+ (setq mode-line-info " by name"))
+
+ ((string-match-p
+ dired-sort-by-date-regexp dired-actual-switches)
+ (setq mode-line-info " by date"))
+
+ (t
+ (setq mode-line-info " by user")))
+ mode-line-info)))
+
(define-obsolete-function-alias 'dired-sort-set-modeline
#'dired-sort-set-mode-line "24.3")
@@ -4174,7 +4201,7 @@
dired-actual-switches)
"t"
" -t")))))
- (dired-sort-set-mode-line)
+ (dired-set-mode-line)
(revert-buffer))
;; Some user code loads dired especially for this.
@@ -4197,7 +4224,7 @@
With optional second arg NO-REVERT, don't refresh the listing afterwards."
(dired-sort-R-check switches)
(setq dired-actual-switches switches)
- (dired-sort-set-mode-line)
+ (dired-set-mode-line)
(or no-revert (revert-buffer)))
(defvar-local dired-subdir-alist-pre-R nil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 16:04:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> Sorry. `diredp' should be `dired' everywhere.
> This patch takes care of that typo.
Looks good to me, so I've now applied your patch to Emacs 28.
Some bikeshedding ensued, and people should feel free to alter the code
(as-is vs t, for instance).
And I'm not sure about this:
+ (concat " " xs (and (< l2 l1) "…")))))
Perhaps that should be conditional upon the terminal being able to
display that character?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 30 Sep 2020 16:04:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
41250 <at> debbugs.gnu.org and Arthur Miller <arthur.miller <at> live.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 30 Sep 2020 16:04:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 19:20:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> Drew Adams <drew.adams <at> oracle.com> writes:
>
>> Sorry. `diredp' should be `dired' everywhere.
>> This patch takes care of that typo.
>
> Looks good to me, so I've now applied your patch to Emacs 28.
>
> Some bikeshedding ensued, and people should feel free to alter the code
> (as-is vs t, for instance).
I recall I asked for 't' instead of 'as-is', but actually 'as-is' is fine
as a value as long as it is not checked for this value in function body.
And indeed it's on the 't' branch of 'cond'.
> And I'm not sure about this:
>
> + (concat " " xs (and (< l2 l1) "…")))))
>
> Perhaps that should be conditional upon the terminal being able to
> display that character?
Like everywhere else (if (char-displayable-p ?…) "…" "...")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 19:32:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> And I'm not sure about this:
>>
>> + (concat " " xs (and (< l2 l1) "…")))))
>>
>> Perhaps that should be conditional upon the terminal being able to
>> display that character?
>
> Like everywhere else (if (char-displayable-p ?…) "…" "...")
Yes. But this is surely a general problem, and:
`truncate-string-to-width'.
----
If ELLIPSIS is non-nil, it should be a string which will replace the
end of STR (including any padding) if it extends beyond END-COLUMN,
unless the display width of STR is equal to or less than the display
width of ELLIPSIS. If it is non-nil and not a string, then ELLIPSIS
defaults to ‘truncate-string-ellipsis’.
----
*sigh*
Would anybody mind very much if I added a `string-truncate-right' that
does all this automatically, and amend `string-truncate-left' in the
same way? I.e., use (if (char-displayable-p ?…) "…" "...").
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 19:59:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> Would anybody mind very much if I added a `string-truncate-right' that
> does all this automatically, and amend `string-truncate-left' in the
> same way? I.e., use (if (char-displayable-p ?…) "…" "...").
There is a better function 'truncate-string-to-width'.
But users need to set up 'truncate-string-ellipsis' explicitly
in init files as
(with-eval-after-load 'mule-util
(setq truncate-string-ellipsis "…"))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 20:00:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> There is a better function 'truncate-string-to-width'.
I mentioned that in the previous paragraph. :-/
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 20:59:01 GMT)
Full text and
rfc822 format available.
Message #126 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> And I'm not sure about this:
>
> + (concat " " xs (and (< l2 l1)
> "…")))))
>
> Perhaps that should be conditional upon the terminal being able to
> display that character?
Interesting. Dunno why I used that char (which I guess is HORIZONTAL
ELLIPSIS). In my own code I in fact use "..." (3 period chars).
Maybe I tossed in an ellipsis char because others in the thread were
worried about losing mode-line space.
(FWIW, I had that ellipsis char in Emacs doc etc. At least in the
fonts I use (fixed width) it's so tiny as to be illegible. An
ellipsis in ordinary printed text is quite a bit wider than other
chars (which are anyway of unequal width). That Unicode provides a
single char for ellipsis is not a reason that we have to, or should,
use it. I think it works against readability - everywhere I've seen
it in Emacs.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 30 Sep 2020 21:08:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > And I'm not sure about this:
> >
> > + (concat " " xs (and (< l2 l1)
> "…")))))
> >
> > Perhaps that should be conditional upon the terminal being able to
> > display that character?
>
> Like everywhere else (if (char-displayable-p ?…) "…" "...")
I'd argue (but not forcefully) for just "...". As I
mentioned, "…" is, for me, useless as an ellipsis. I think
it must be useless for nearly everyone, with a fixed-width
font.
I imagine that I included it in the patch (it's not in my
code, which is otherwise identical to what's in the patch)
only because some were worried about mode-line real estate.
Maybe it's worth a defvar (string value), so code that wants
to tweak the mode-line can adapt it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 01:27:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> I'd argue (but not forcefully) for just "...". As I
> mentioned, "…" is, for me, useless as an ellipsis. I think
> it must be useless for nearly everyone, with a fixed-width
> font.
I kinda like … because it takes up so little space, and the reason we're
normally truncating strings is because they take up too much space. So
using that limited space for "..." is counter-productive.
But this should be standardised throughout Emacs, and work out of the
box automatically on systems that can display the character and not,
which makes truncate-string-to-width less than ideal.
There also, of course, the issue of "well, if the call says 'truncate to
15 characters', how much should we remove when we add the …?" Because …
usually takes a bit more than a single normal character to display,
while "..." takes three.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 02:31:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 30 Sep 2020 21:30:56 +0200
> Cc: 41250 <at> debbugs.gnu.org, Arthur Miller <arthur.miller <at> live.com>
>
> Would anybody mind very much if I added a `string-truncate-right' that
> does all this automatically, and amend `string-truncate-left' in the
> same way? I.e., use (if (char-displayable-p ?…) "…" "...").
That could be useful, but it would be better if the name hinted on the
fact that char-displayable-p is involved.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 02:41:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Would anybody mind very much if I added a `string-truncate-right' that
>> does all this automatically, and amend `string-truncate-left' in the
>> same way? I.e., use (if (char-displayable-p ?…) "…" "...").
>
> That could be useful, but it would be better if the name hinted on the
> fact that char-displayable-p is involved.
Uhm... truncate-string-prettily?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 09:25:02 GMT)
Full text and
rfc822 format available.
Message #141 received at submit <at> debbugs.gnu.org (full text, mbox):
On Thu 01 Oct 2020, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Would anybody mind very much if I added a `string-truncate-right' that
>>> does all this automatically, and amend `string-truncate-left' in the
>>> same way? I.e., use (if (char-displayable-p ?…) "…" "...").
>>
>> That could be useful, but it would be better if the name hinted on the
>> fact that char-displayable-p is involved.
>
> Uhm... truncate-string-prettily?
Using truncate could lead to confusion with string-trim-{left,right}.
Perhaps string-elide-left etc ?
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 16:38:01 GMT)
Full text and
rfc822 format available.
Message #144 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> > I'd argue (but not forcefully) for just "...". As I
> > mentioned, "…" is, for me, useless as an ellipsis. I think
> > it must be useless for nearly everyone, with a fixed-width
> > font.
>
> I kinda like … because it takes up so little space, and the reason we're
> normally truncating strings is because they take up too much space. So
> using that limited space for "..." is counter-productive.
It's not about losing any more mode-line space.
Instead, it should be about losing 2 more chars
from the info displayed for this in the mode-line.
> But this should be standardised throughout Emacs, and work out of the
> box automatically on systems that can display the character and not,
> which makes truncate-string-to-width less than ideal.
>
> There also, of course, the issue of "well, if the call says 'truncate to
> 15 characters', how much should we remove when we add the …?" Because …
> usually takes a bit more than a single normal character to display,
> while "..." takes three.
FTR, I disagree.
Better to truncate an additional 2 chars and use a
"real" ellipsis: "...". The single char ellipsis
is awful, at least in any fixed-width font I've used.
If we're truncating, we're truncating. Truncating 2
more chars is not so bad. It's more important to
clearly pass the message that the thing _is_ truncated.
And the ellipsis char doesn't do that clearly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 19:51:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> There is a better function 'truncate-string-to-width'.
>
> I mentioned that in the previous paragraph. :-/
Oh, sorry.
But anyway I think that it would be better to keep 'truncate-string-to-width',
and to turn 'truncate-string-ellipsis' into a user option (defvar -> defcustom)
with the default value computed as (if (char-displayable-p ?…) "…" "...")
If this doesn't work on dynamically created mixed X/tty frames,
then maybe allow some value (e.g. 'auto-detect') for 'truncate-string-ellipsis',
so 'truncate-string-to-width' would call (if (char-displayable-p ?…) "…" "...")
every time when 'truncate-string-to-width' is used and recompute the value of
ellipsis.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 20:00:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> But anyway I think that it would be better to keep
> 'truncate-string-to-width', and to turn 'truncate-string-ellipsis'
> into a user option (defvar -> defcustom) with the default value
> computed as (if (char-displayable-p ?…) "…" "...")
>
> If this doesn't work on dynamically created mixed X/tty frames, then
> maybe allow some value (e.g. 'auto-detect') for
> 'truncate-string-ellipsis', so 'truncate-string-to-width' would call
> (if (char-displayable-p ?…) "…" "...") every time when
> 'truncate-string-to-width' is used and recompute the value of
> ellipsis.
The variable doesn't work as is (because of the problem of mixed
frames), and `auto-detect' doesn't have much meaning, which is why this
should never have been a variable in the first place.
Instead of trying to fix that mess, I thought it would be easier to
introduce a new function that does the right thing automatically, and
without a gazillion optional parameters, and then make the old function
obsolete.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Thu, 01 Oct 2020 20:03:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Perhaps call it... `limit-string-for-display'... And it could work for
the displayed pixel width of all the characters involved, so that it'd
also work on variable-pitch characters (and compute the correct length
occupied for … vs ..., too.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 06:33:01 GMT)
Full text and
rfc822 format available.
Message #156 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 01 Oct 2020 21:59:13 +0200
> Cc: 41250 <at> debbugs.gnu.org, Arthur Miller <arthur.miller <at> live.com>
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> > But anyway I think that it would be better to keep
> > 'truncate-string-to-width', and to turn 'truncate-string-ellipsis'
> > into a user option (defvar -> defcustom) with the default value
> > computed as (if (char-displayable-p ?…) "…" "...")
> >
> > If this doesn't work on dynamically created mixed X/tty frames, then
> > maybe allow some value (e.g. 'auto-detect') for
> > 'truncate-string-ellipsis', so 'truncate-string-to-width' would call
> > (if (char-displayable-p ?…) "…" "...") every time when
> > 'truncate-string-to-width' is used and recompute the value of
> > ellipsis.
>
> The variable doesn't work as is (because of the problem of mixed
> frames), and `auto-detect' doesn't have much meaning, which is why this
> should never have been a variable in the first place.
>
> Instead of trying to fix that mess, I thought it would be easier to
> introduce a new function that does the right thing automatically, and
> without a gazillion optional parameters, and then make the old function
> obsolete.
How about making char-displayable-p accept an optional argument, a
frame for which to perform the test?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 07:00:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> The variable doesn't work as is (because of the problem of mixed
> frames), and `auto-detect' doesn't have much meaning, which is why this
> should never have been a variable in the first place.
>
> Instead of trying to fix that mess, I thought it would be easier to
> introduce a new function that does the right thing automatically, and
> without a gazillion optional parameters, and then make the old function
> obsolete.
I have no opinion about a new function. Like everyone else, I'm using
truncate-string-to-width, and happy with it, except of one complaint:
on every use I need to wrap it with such code:
(let ((ellipsis (cond
(truncate-string-ellipsis)
((char-displayable-p ?…) "…")
("..."))))
(truncate-string-to-width string max nil nil ellipsis))
Preferably, this should be fixed with this patch:
[truncate-string-ellipsis.patch (text/x-diff, inline)]
diff --git a/lisp/international/mule-util.el b/lisp/international/mule-util.el
index 660ac58e02..a2bd5802cc 100644
--- a/lisp/international/mule-util.el
+++ b/lisp/international/mule-util.el
@@ -44,10 +44,16 @@ store-substring
(setq i (1+ i)))))
string)
-(defvar truncate-string-ellipsis "..." ;"…"
+(defvar truncate-string-ellipsis nil
"String to use to indicate truncation.
Serves as default value of ELLIPSIS argument to `truncate-string-to-width'.")
+(defun truncate-string-ellipsis ()
+ (cond
+ (truncate-string-ellipsis)
+ ((char-displayable-p ?…) "…")
+ ("...")))
+
;;;###autoload
(defun truncate-string-to-width (str end-column
&optional start-column padding ellipsis
@@ -81,7 +87,7 @@ truncate-string-to-width
(or start-column
(setq start-column 0))
(when (and ellipsis (not (stringp ellipsis)))
- (setq ellipsis truncate-string-ellipsis))
+ (setq ellipsis (truncate-string-ellipsis)))
(let ((str-len (length str))
(str-width (string-width str))
(ellipsis-width (if ellipsis (string-width ellipsis) 0))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 14:11:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> How about making char-displayable-p accept an optional argument, a
> frame for which to perform the test?
I thought char-displayable-p worked based on the current frame? Which
is what we'd want in a truncate-string-visually function (or whatever
it'd be called). But having that function take an optional frame
parameter wouldn't help with the initialisation of the
'truncate-string-ellipsis' variable (a variable I think is misguided)...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 14:15:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> I have no opinion about a new function. Like everyone else, I'm using
> truncate-string-to-width, and happy with it, except of one complaint:
> on every use I need to wrap it with such code:
>
> (let ((ellipsis (cond
> (truncate-string-ellipsis)
> ((char-displayable-p ?…) "…")
> ("..."))))
> (truncate-string-to-width string max nil nil ellipsis))
>
> Preferably, this should be fixed with this patch:
Your patch is a distinct improvement on the current state of affairs, so
please go ahead and push to master (with a NEWS item).
A new function that's more pixel-aware can be added at a later date, and
is pretty much an orthogonal issue anyway.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: juri <at> linkov.net, 41250 <at> debbugs.gnu.org, arthur.miller <at> live.com
> Date: Fri, 02 Oct 2020 16:10:41 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > How about making char-displayable-p accept an optional argument, a
> > frame for which to perform the test?
>
> I thought char-displayable-p worked based on the current frame?
The selected-frame, yes. I though that wasn't good enough in this
case, but maybe I was confused? If the latter, what exactly is the
problem that caused you to say "The variable doesn't work as is
(because of the problem of mixed frames)"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Fri, 02 Oct 2020 15:00:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 02 Oct 2020 16:14:31 +0200
> Cc: 41250 <at> debbugs.gnu.org, Arthur Miller <arthur.miller <at> live.com>
>
> > (let ((ellipsis (cond
> > (truncate-string-ellipsis)
> > ((char-displayable-p ?…) "…")
> > ("..."))))
> > (truncate-string-to-width string max nil nil ellipsis))
> >
> > Preferably, this should be fixed with this patch:
>
> Your patch is a distinct improvement on the current state of affairs, so
> please go ahead and push to master (with a NEWS item).
>
> A new function that's more pixel-aware can be added at a later date, and
> is pretty much an orthogonal issue anyway.
To be pixel-aware, we need to use window-text-pixel-size.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 03 Oct 2020 17:37:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > How about making char-displayable-p accept an optional argument, a
>> > frame for which to perform the test?
>>
>> I thought char-displayable-p worked based on the current frame?
>
> The selected-frame, yes. I though that wasn't good enough in this
> case, but maybe I was confused? If the latter, what exactly is the
> problem that caused you to say "The variable doesn't work as is
> (because of the problem of mixed frames)"?
There's a variable -- 'truncate-string-ellipsis' -- set globally, and
it was suggested that the default of that variable should depend on
char-displayable-p. I pointed out that that isn't very useful, in
general, in a mixed frame situation.
The char-displayable-p function is fine as is, though.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sat, 03 Oct 2020 17:40:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> To be pixel-aware, we need to use window-text-pixel-size.
Yup. This is the strategy that eww--pixel-column and friends use to
figure out where to truncate the title in the header line of the eww
buffers.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Sun, 04 Oct 2020 19:47:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> on every use I need to wrap it with such code:
>>
>> (let ((ellipsis (cond
>> (truncate-string-ellipsis)
>> ((char-displayable-p ?…) "…")
>> ("..."))))
>> (truncate-string-to-width string max nil nil ellipsis))
>>
>> Preferably, this should be fixed with this patch:
>
> Your patch is a distinct improvement on the current state of affairs, so
> please go ahead and push to master (with a NEWS item).
Pushed now with a NEWS item.
When I grepped for more usages of truncate-string-to-width, I found
one call in Gnus. It seems this patch could improve gnus-set-mode-line,
but I'm not sure, and moreover I have no idea how to test this:
diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el
index b3ed5cb664..42ba4fbd71 100644
--- a/lisp/gnus/gnus-sum.el
+++ b/lisp/gnus/gnus-sum.el
@@ -6240,8 +6240,7 @@ gnus-set-mode-line
;; We might have to chop a bit of the string off...
(when (> (length mode-string) max-len)
(setq mode-string
- (concat (truncate-string-to-width mode-string (- max-len 3))
- "...")))))
+ (truncate-string-to-width mode-string (- max-len 3) nil nil t)))))
;; Update the mode line.
(setq mode-line-buffer-identification
(gnus-mode-line-buffer-identification (list mode-string)))
Here is another function, and it needs not just an improvement,
but a plain bug fix because its args were wrong, and this patch should fix
its args, but again currently I don't yet know how to test this:
diff --git a/lisp/ibuffer.el b/lisp/ibuffer.el
index c9a748830c..8ff3b56c5e 100644
--- a/lisp/ibuffer.el
+++ b/lisp/ibuffer.el
@@ -1597,7 +1597,7 @@ ibuffer-compile-make-eliding-form
(defun ibuffer-compile-make-substring-form (strvar maxvar from-end-p)
(if from-end-p
;; FIXME: not sure if this case is correct (Bug#24972)
- `(truncate-string-to-width str strlen (- strlen ,maxvar) nil ?\s)
+ `(truncate-string-to-width str strlen (- strlen ,maxvar) ?\s)
`(truncate-string-to-width ,strvar ,maxvar nil ?\s)))
(defun ibuffer-compile-make-format-form (strvar widthform alignment)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 07:09:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Pushed now with a NEWS item.
Great!
> When I grepped for more usages of truncate-string-to-width, I found
> one call in Gnus. It seems this patch could improve gnus-set-mode-line,
> but I'm not sure, and moreover I have no idea how to test this:
[...]
> - (concat (truncate-string-to-width mode-string (- max-len 3))
> - "...")))))
> + (truncate-string-to-width mode-string (- max-len 3) nil nil t)))))
I applied the patch and tested it, and it looks fine, so I've pushed it
to Emacs 28.
> Here is another function, and it needs not just an improvement,
> but a plain bug fix because its args were wrong, and this patch should fix
> its args, but again currently I don't yet know how to test this:
[...]
> - `(truncate-string-to-width str strlen (- strlen ,maxvar) nil ?\s)
> + `(truncate-string-to-width str strlen (- strlen ,maxvar) ?\s)
> `(truncate-string-to-width ,strvar ,maxvar nil ?\s)))
Testing should be pretty easy -- just say `M-x ibuffer' and look at how
it truncates buffer names. :-)
However, the patch doesn't fix the ellipsis stuff here, because ibuffer
has a `ibuffer-eliding-string' variable (that could be obsoleted now).
(But the patch otherwise looks "obviously correct" to me; passing in ?\s
as the ellipsis argument doesn't make much sense.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 15:50:01 GMT)
Full text and
rfc822 format available.
Message #186 received at 41250 <at> debbugs.gnu.org (full text, mbox):
5ec2115 seems to cause a build failure in some cases.
Ref https://hydra.nixos.org/build/128075429
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 20:24:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> 5ec2115 seems to cause a build failure in some cases.
> Ref https://hydra.nixos.org/build/128075429
I tried to bootstrap several times, but can't reproduce the error.
Here are the relevant parts of the hydra log:
make -C ../leim all EMACS="../src/bootstrap-emacs"
GEN ../lisp/leim/ja-dic/ja-dic.el
INFO Processing OKURI-ARI entries
INFO Processing POSTFIX entries
Loading macroexp.elc...
Invalid read syntax: "?"
make[3]: *** [Makefile:143: ../lisp/leim/ja-dic/ja-dic.el] Error 255
When I tried the command
make -C leim all EMACS="../src/bootstrap-emacs"
its output was:
GEN ../lisp/leim/ja-dic/ja-dic.el
INFO Processing OKURI-ARI entries
INFO Processing POSTFIX entries
Source file `lisp/international/mule-util.el' newer than byte-compiled file; using older file
INFO Processing PREFIX entries
...
INFO Processing OKURI-NASI entries...done
and successfully finished. The interesting line is
"Source file `lisp/international/mule-util.el' newer"
this means that skkdic-convert-postfix in ja-dic-cnv.el
calls set-nested-alist that autoloads mule-util.el.
So the question is why loading mule-util.el produces this error?
It seems loading can't parse this recently added line:
(char-displayable-p ?…)
and gives the error `Invalid read syntax: "?"`.
Maybe this Unicode character should be replaced in the source file
with its name:
(char-displayable-p ?\N{HORIZONTAL ELLIPSIS})
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 20:24:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> - `(truncate-string-to-width str strlen (- strlen ,maxvar) nil ?\s)
>> + `(truncate-string-to-width str strlen (- strlen ,maxvar) ?\s)
>> `(truncate-string-to-width ,strvar ,maxvar nil ?\s)))
>
> Testing should be pretty easy -- just say `M-x ibuffer' and look at how
> it truncates buffer names. :-)
>
> However, the patch doesn't fix the ellipsis stuff here, because ibuffer
> has a `ibuffer-eliding-string' variable (that could be obsoleted now).
Yep, this is what I tried, but it had no immediate effect :-)
> (But the patch otherwise looks "obviously correct" to me; passing in ?\s
> as the ellipsis argument doesn't make much sense.)
It seems this code is over-complicated with several levels of backquoting.
So maybe better just to push this obvious fix.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 21:32:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 05 2020, Juri Linkov wrote:
> So the question is why loading mule-util.el produces this error?
Because skkdic-convert binds coding-system-for-read to euc-japan.
$ ../src/bootstrap-emacs -batch --eval "(let ((coding-system-for-read 'euc-japan)) (require 'mule-util))"
Invalid read syntax: "?"
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Mon, 05 Oct 2020 23:07:02 GMT)
Full text and
rfc822 format available.
Message #198 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov wrote:
>> 5ec2115 seems to cause a build failure in some cases.
>> Ref https://hydra.nixos.org/build/128075429
>
> I tried to bootstrap several times, but can't reproduce the error.
I think doing a non-parallel build in a completely clean tree (not just
a bootstrap) should make it reproducible.
> make -C leim all EMACS="../src/bootstrap-emacs"
> Source file `lisp/international/mule-util.el' newer than byte-compiled file; using older file
leim/Makefile.in should probably set load-prefer-newer,
as lisp/Makefile.in does.
> So the question is why loading mule-util.el produces this error?
Thanks to Andreas for answering that. Simply making ja-dic-cnv.el
require mule-util at top-level seems to avoid the problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 01:39:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> (But the patch otherwise looks "obviously correct" to me; passing in ?\s
>> as the ellipsis argument doesn't make much sense.)
>
> It seems this code is over-complicated with several levels of backquoting.
> So maybe better just to push this obvious fix.
Yup.
And ibuffer probably can't use the ellipsis stuff from the function
anyway, because it wants to create a tabulated buffer layout, and
assumes that all the characters have the same width. (I've just skimmed
the code; I may well be wrong here.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 07:14:01 GMT)
Full text and
rfc822 format available.
Message #204 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 05 2020, Glenn Morris wrote:
> Thanks to Andreas for answering that. Simply making ja-dic-cnv.el
> require mule-util at top-level seems to avoid the problem?
Autoloading should probably bind coding-system-for-read to nil.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 07:19:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Date: Tue, 06 Oct 2020 09:13:21 +0200
> Cc: 41250 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
> Arthur Miller <arthur.miller <at> live.com>, Juri Linkov <juri <at> linkov.net>
>
> On Okt 05 2020, Glenn Morris wrote:
>
> > Thanks to Andreas for answering that. Simply making ja-dic-cnv.el
> > require mule-util at top-level seems to avoid the problem?
>
> Autoloading should probably bind coding-system-for-read to nil.
Perhaps if it is not already bound to something. But not
unconditionally, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 07:29:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 06 Oct 2020 10:18:17 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 41250 <at> debbugs.gnu.org, rgm <at> gnu.org, larsi <at> gnus.org, arthur.miller <at> live.com,
> juri <at> linkov.net
>
> > Autoloading should probably bind coding-system-for-read to nil.
>
> Perhaps if it is not already bound to something. But not
> unconditionally, I think.
Actually, aren't *.elc files always encoded in utf-8-emacs? If so,
perhaps we should treat them as such in load-with-code-conversion,
bypassing coding-system-for-read entirely?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 07:49:02 GMT)
Full text and
rfc822 format available.
Message #213 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Eli Zaretskii wrote:
> Actually, aren't *.elc files always encoded in utf-8-emacs?
This is about uncompiled files.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 07:54:01 GMT)
Full text and
rfc822 format available.
Message #216 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> > Thanks to Andreas for answering that. Simply making ja-dic-cnv.el
>> > require mule-util at top-level seems to avoid the problem?
>>
>> Autoloading should probably bind coding-system-for-read to nil.
>
> Perhaps if it is not already bound to something. But not
> unconditionally, I think.
As a quick fix before deciding for a more general solution
I replaced the character with its name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 08:19:01 GMT)
Full text and
rfc822 format available.
Message #219 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: 41250 <at> debbugs.gnu.org, rgm <at> gnu.org, larsi <at> gnus.org,
> arthur.miller <at> live.com, juri <at> linkov.net
> Date: Tue, 06 Oct 2020 09:48:26 +0200
>
> On Okt 06 2020, Eli Zaretskii wrote:
>
> > Actually, aren't *.elc files always encoded in utf-8-emacs?
>
> This is about uncompiled files.
But the error message which started this bug report was about
macroexp.elc, no? I guess I'm missing something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 08:45:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Eli Zaretskii wrote:
> But the error message which started this bug report was about
> macroexp.elc, no?
No, this is unrelated. It just happend to be loaded at the same time.
See the recipe in <87mu10s6kn.fsf <at> igel.home>.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 09:04:02 GMT)
Full text and
rfc822 format available.
Message #225 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: 41250 <at> debbugs.gnu.org, rgm <at> gnu.org, larsi <at> gnus.org,
> arthur.miller <at> live.com, juri <at> linkov.net
> Date: Tue, 06 Oct 2020 10:44:30 +0200
>
> On Okt 06 2020, Eli Zaretskii wrote:
>
> > But the error message which started this bug report was about
> > macroexp.elc, no?
>
> No, this is unrelated. It just happend to be loaded at the same time.
Ah, okay.
So perhaps adding a coding: cookie in mule-utils.el would solve this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 09:18:02 GMT)
Full text and
rfc822 format available.
Message #228 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Eli Zaretskii wrote:
> So perhaps adding a coding: cookie in mule-utils.el would solve this?
No, coding-system-for-read takes precedence.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 09:25:02 GMT)
Full text and
rfc822 format available.
Message #231 received at 41250 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: 41250 <at> debbugs.gnu.org, rgm <at> gnu.org, larsi <at> gnus.org,
> arthur.miller <at> live.com, juri <at> linkov.net
> Date: Tue, 06 Oct 2020 11:17:55 +0200
>
> On Okt 06 2020, Eli Zaretskii wrote:
>
> > So perhaps adding a coding: cookie in mule-utils.el would solve this?
>
> No, coding-system-for-read takes precedence.
Perhaps this is what we should change in load-with-code-conversion?
Does it make sense to have any coding-system-for-read except
no-conversion take precedence over an explicit file-local encoding
value of a .el file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 09:46:02 GMT)
Full text and
rfc822 format available.
Message #234 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Eli Zaretskii wrote:
> Perhaps this is what we should change in load-with-code-conversion?
> Does it make sense to have any coding-system-for-read except
> no-conversion take precedence over an explicit file-local encoding
> value of a .el file?
That's basically what I proposed.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 11:37:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 41250 <at> debbugs.gnu.org (full text, mbox):
To repair the build, I changed from \N{...} to hex escapes. Perhaps you want a different solution eventually.
Putting (require 'mule-util) at the top level of ja-dic-cnv.el doesn't help -- \N{...} escapes don't seem to work at this stage of the build.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 13:09:01 GMT)
Full text and
rfc822 format available.
Message #240 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> So the question is why loading mule-util.el produces this error?
> Because skkdic-convert binds coding-system-for-read to euc-japan.
>
> $ ../src/bootstrap-emacs -batch --eval "(let ((coding-system-for-read
> 'euc-japan)) (require 'mule-util))"
> Invalid read syntax: "?"
Does the patch below address the issue?
Stefan
diff --git a/lisp/international/ja-dic-cnv.el b/lisp/international/ja-dic-cnv.el
index f5e70ce702..5f645b6e8e 100644
--- a/lisp/international/ja-dic-cnv.el
+++ b/lisp/international/ja-dic-cnv.el
@@ -329,12 +329,12 @@ skkdic-convert
the generated Emacs Lisp is saved.
The name of generated file is specified by the variable `ja-dic-filename'."
(interactive "FSKK dictionary file: ")
- (let* ((coding-system-for-read 'euc-japan)
- (skkbuf (get-buffer-create " *skkdic-unannotated*"))
+ (let* ((skkbuf (get-buffer-create " *skkdic-unannotated*"))
(buf (get-buffer-create "*skkdic-work*")))
;; Set skkbuf to an unannotated copy of the dictionary.
(with-current-buffer skkbuf
- (insert-file-contents (expand-file-name filename))
+ (let ((coding-system-for-read 'euc-japan))
+ (insert-file-contents (expand-file-name filename)))
(re-search-forward "^[^;]")
(while (re-search-forward ";[^\n/]*/" nil t)
(replace-match "/")))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 13:29:02 GMT)
Full text and
rfc822 format available.
Message #243 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Stefan Monnier wrote:
>>> So the question is why loading mule-util.el produces this error?
>> Because skkdic-convert binds coding-system-for-read to euc-japan.
>>
>> $ ../src/bootstrap-emacs -batch --eval "(let ((coding-system-for-read
>> 'euc-japan)) (require 'mule-util))"
>> Invalid read syntax: "?"
>
> Does the patch below address the issue?
It is the right way to use coding-system-for-read in any case.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Tue, 06 Oct 2020 15:26:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 41250 <at> debbugs.gnu.org (full text, mbox):
On Okt 06 2020, Stefan Monnier wrote:
> I don't know how to reproduce the original proble
The problem only happens if you start with a pristine checkout of the
sources, or run make extraclean (which also deletes lisp/leim/ja-dic,
unlike make bootstrap), and you are lucky enough that lisp/leim/ja-dic
happens to be recreated before lisp/international/mule-util.elc.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 07 Oct 2020 07:35:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > I don't know how to reproduce the original proble
>
> The problem only happens if you start with a pristine checkout of the
> sources, or run make extraclean (which also deletes lisp/leim/ja-dic,
> unlike make bootstrap), and you are lucky enough that lisp/leim/ja-dic
> happens to be recreated before lisp/international/mule-util.elc.
>
This is exactly how I build master: checkout the repo then autogen &&
configure && make.
Thanks, I'll watch #41250 then.
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 07 Oct 2020 07:37:01 GMT)
Full text and
rfc822 format available.
Message #252 received at 41250 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> This has recently been addressed in `emacs` with a series of 3 commits
> each trying to fix it slightly differently.
> I don't know how to reproduce the original proble, so if it affects you,
> can you try the most recent `master` and see if it still affects you?
>
The recent changes has fixed the problem for me (
https://gitlab.com/Silex777/docker-emacs/-/pipelines/198745106)
Thanks,
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 07 Oct 2020 13:07:02 GMT)
Full text and
rfc822 format available.
Message #255 received at 41250 <at> debbugs.gnu.org (full text, mbox):
>> This has recently been addressed in `emacs` with a series of 3 commits
>> each trying to fix it slightly differently.
>> I don't know how to reproduce the original proble, so if it affects you,
>> can you try the most recent `master` and see if it still affects you?
> The recent changes has fixed the problem for me (
> https://gitlab.com/Silex777/docker-emacs/-/pipelines/198745106)
Good to hear, thank you,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#41250; Package
emacs.
(Wed, 07 Oct 2020 15:56:01 GMT)
Full text and
rfc822 format available.
Message #258 received at 41250 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Since ~2 days the branch master refuses to build in my docker images,
>> is this known/normal?
>>
>> #38 435.6 Loading macroexp.elc...
>> #38 435.6 Invalid read syntax: "?"
>>
>> https://gitlab.com/Silex777/docker-emacs/-/jobs/774443194
>
> This has recently been addressed in `emacs` with a series of 3 commits
> each trying to fix it slightly differently.
> I don't know how to reproduce the original proble, so if it affects you,
> can you try the most recent `master` and see if it still affects you?
I had a similar "Invalid read syntax" error when doing `eval-buffer'
while AUCTeX' texmathp.el was opened (but didn't have time to report
it). With the current master, it works again.
Bye,
Tassilo
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 05 Nov 2020 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 43 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.