GNU bug report logs - #64160
master; Implement various enhancements in ldap.el and EUDC

Previous Next

Full log

View this message in rfc822 format

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 64160 <at> debbugs.gnu.org
Subject: bug#64160: bug#64089: 30.0.50; `ldap-search' errors out with `wrong-type-argument listp' when called WITHDN == t
Date: Mon, 19 Jun 2023 17:11:55 +0300

Hi Jens,

On 19/06/2023 00:14 +0200, Jens Schmidt wrote:

> Hi Filipp,
>
> On 2023-06-18  09:43, Jens Schmidt wrote:
>
>> [...]  In any case, I'll open a new bug for that to continue this
>> discussion.
>
> here is the bug I've opened as master tracking bug: bug#64160 (CCed as
> well).

I think I'll merge that into this bug - no need for two bugs, the issue
is the same.

Regarding your proposal from the other message:

> I think we should account (in emacs-master) for these various options
> and make WITHDN take various values:
> 
>   `cons'   - return my interpretation
>   `string' - return yours
>   t        - return Gerd's

This is overkill in my eyes, as we don't have enough user feedback to
request for those options.

> I'd appreciate contributing together with you, and your hint on the
> role of `ldap-ignore-attribute-codings' was really helpful, thanks.
> But some others of the changes you have been proposing were not very
> helpful for what I have in mind.  For example:
>
>> 3) (unrelated, just noticed and fixed) Match data clobbering in this
>> piece:
>>
>> -            ;; Need to handle file:///D:/... as generated by OpenLDAP
>> -            ;; on DOS/Windows as local files.
>> -            (if (and (memq system-type '(windows-nt ms-dos))
>> -                     (eq (string-match "/\\(.:.*\\)$" value) 0))
>> -                (setq value (match-string 1 value)))
>
> This piece of code handling temp files on DOS/Windows should in my
> opinion be moved into the following `(if (match-string 3) ...' clause,
> which handles temp files in general.  (In that case the
> `save-match-data' would no longer be required, BTW.)

Yes, it could, I just rather avoid moving code where it's not very
necessary.

> On 2023-06-17  00:13, Filipp Gunbin wrote:
>
>> Please give it a try, if it's OK and others have no objections, I'll
>> install it on Monday (on master, I guess).
>
> So could you please wait with your commit until we have something
> worked out that works for all?

So what problem is left now for you?

I think we should leave emacs-29 out, so, after you write back, I'm
intending to:

- Fix what else you report (if anything)

- Revert what was installed on emacs-29.  It seems that the correct fix
  would not be trivial enough.

- Install full fix on master - we can discuss which version, however I
  don't see strong benefits of one vs. the other, so let's save time.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.