[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-ASCII TAGS
Re: non-ASCII TAGS
Wed, 23 Apr 2003 20:01:04 +0900 (JST)
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)
Sorry for the late response on this matter.
In article <address@hidden>, Dave Love <address@hidden> writes:
> Probably the worst problem with using non-ASCII programming
> identifiers is etags. It isn't aware of encoding issues and fixing
> the issues is non-trivial, so this is mainly raising a flag and hoping
> someone can work on it. I think sorting it out requires not only
> extending the TAGS format, but probably also generating it with Emacs.
> I don't have time to work on this, but here's the problem and some
What do you think about the following proposal which, I
think, work in most cases without extending the TAGS format.
In the case it doesn't work, we can still ask people to use
C-x RET c __CODING__ RET ESC . .
Of course, as you wrote, recoding coding systems in TAGS is
ideal, but it requires more work just to save rare cases.
Kenichi Handa <address@hidden> writes:
> In article <address@hidden>, Karl Eichwalder <address@hidden> writes:
>> Now the next one: `tags-query-replace' does not work properly when file
>> names are UTF-8 encoded. First run `etags *' on the files and then
>> call `tags-query-replace'.
> This is the same type of bug (but more difficult) as what I
> posted to emacs-devel by the subjest "bad interaction with
> C-x RET c and vc-cvs-registered".
> A tag file contains file names plus parts of source code.
> The former must be decoded by file-name-coding-system, but
> the latter must be decoded by the coding system of each
> file. It's very hard to decided a coding system for the
> latter without actually reading the file.
> Perhaps, a tag file must be read as raw-text (thus in a
> unibyte buffer), and if one gives a non-ASCII TAGNAME to
> `find-tag', it must be encoded by the
> buffer-file-coding-system of the current buffer.
And the reply from Richard is as follows:
> That seems like a good approach. Would someone like to implement it?
- non-ASCII TAGS, Dave Love, 2003/04/02
- Re: non-ASCII TAGS,
Kenichi Handa <=