emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/3] lisp/progmodes/etags.el don't (forward-char) as it's ove


From: Konstantin Kharlamov
Subject: Re: [PATCH 2/3] lisp/progmodes/etags.el don't (forward-char) as it's overriden next line
Date: Tue, 19 Mar 2019 02:38:54 +0300



В Вт, мар 19, 2019 at 2:13 ДП (AM), Konstantin Kharlamov <address@hidden> написал:


В Вт, мар 19, 2019 at 12:45 ДП (AM), Konstantin Kharlamov <address@hidden> написал:


В Пн, мар 18, 2019 at 11:16 ПП (PM), Eli Zaretskii <address@hidden> написал:
 Date: Mon, 18 Mar 2019 22:15:27 +0300
 From: Konstantin Kharlamov <address@hidden>
 Cc: address@hidden

 > Can you provide those additional details?

 I'm not sure what additional details you want.

OK, let me ask more specific questions:

1. Why was the amount of whitespace in the tags table different from
     that in the source file?

It's a bug in anjuta-tags

  2. What command(s) was/were used to produce the tags table?

anjuta-tags -e file.vala

  3. Why are the issue and you talking about "trailing whitespace",
while the difference between Expected and Actual in the issue is
     in leading whitespace, not trailing whitespace?

Sorry for confusion here, I was imagining: given a string, whitespace may "trail" on both sides of it. But I'm not a native speaker.

 Let's make it the other way around: please, provide any language
 example, where having the trailing space may be significant for
 unambigiously determining the tag.

etags.el doesn't understand any languages, that is the job of the
program that produces the tags table. etags.el just follows the rules for the format of tags in the tags table. I don't know about trailing
whitespace, but tags for HTML files surely include embedded
whitespace, for example.

So once again, I suggest to focus on the particular problem you had,
because I'd like to find a solution for that without making
backward-incompatible changes in behavior of etags.el.

Okay, whatever. I get your position. Though I disagree, but we clearly have different priorities here: while I'm focusing on a Emacs user, you're focusing on technical correctness. I doubt this discussion can move anywhere further, let's leave it at it.

Can my 1-st patch from the series be merged though?

Oh, wait, I noticed despite going to a tag I'm getting "Rerun etags" message. Something is wrong, let me investigate.

Oh, I found my bug, that sucks, don't know how I missed that, I've used that code for a while. I need to return t from the cycle. Basically, I need either "break", or recursion. The first isn't supported in Lisp, and the tail-recursion optimization is not supported in Emacs. So there's actually no way to improve this code.

The patch can be dropped too.





reply via email to

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